Why doesn't Irrlicht use STL?

MasterGod · Post by **MasterGod** » Wed Apr 02, 2008 11:53 am

hybrid wrote:Ok, before someone thinks that we simply ignore this thread: I did vote against the integration of irr::map, because it's awkwardly designed. I did clean up some stuff already, but I won't bother with it more than necessary. That's not true for the other containers, though. I try to fix all problems with those, and enhance their interface while keeping the general use pattern.
However, since I use Irrlicht, the official rule was to avoid all parts of the STL, i.e. all containers, streams, algorithms, everything. Since there had been no other "official announcement", I'll keep it that way.

Does that mean you officially reject any chance that we will convert to STL in the future?

hybrid · Post by **hybrid** » Wed Apr 02, 2008 1:37 pm

No, I just stated that absolute avoidance of any STL construct had been an Irrlicht design requirement ever since, and that this rule has not yet been revoked. And these basic design rules have been strictly kept up until now, so don't know if there are any chances to change one of the more fundamental ones.

rogerborg · Post by **rogerborg** » Wed Apr 02, 2008 2:37 pm

Time for some requirements rules-lawyering.

Is the requirement that Irrlicht avoid using STL, or that Irrlicht avoid being reliant on STL?

Because a compile switch - off by default - would satisfy the latter requirement.

Saturn · Post by **Saturn** » Wed Apr 02, 2008 3:02 pm

Do we await some announcement of some god that decides this is about to be changed or not? I mean who if not the developers decide this.
hybrid, your use of passive voice makes it sound as if you don't have a saying in this and your only executing other parties decisions.

Dorth · Post by **Dorth** » Wed Apr 02, 2008 3:25 pm

I think Hybrid was pretty open on that we could have a core/STL implementation through a switch. Basically, in my 3 steps, we could go to the second one. The third is the real pickle. The removal of the core containers. But quite honestly, that's the one I'm the least attached to. If the containers behave like STL and can be switched for STL, meh. At that point, they become a luxury typedef for those using the STL implementation.

rogerborg · Post by **rogerborg** » Wed Apr 02, 2008 3:27 pm

MasterGod · Post by **MasterGod** » Wed Apr 02, 2008 5:15 pm

@rogerborg: LOOOOOOOOOOOOOOOOOOOOOOOOOOOOOL

Where the hell do you find those amazing images!! (google..)

LMAO xD!!

hybrid · Post by **hybrid** » Wed Apr 02, 2008 7:34 pm

Well, Niko made those general decisions. And the requirement for STL usage is that there must be a fully working version of Irrlicht which does not use any kind of STL related statement, struct, whatever. However, we did not discuss this issue lately, but I'm not aware of any ground-breaking change in the general directions.
Even more important (but also very related) is keeping backward compatibility except for very good reasons. So making an opt-in replacement of the underlying container implementations is definitely no problem. But exposing any of the STL functionality into the API might become problematic.

MasterGod · Post by **MasterGod** » Wed Apr 02, 2008 9:11 pm

I'll say it again cause no one address it.
What about C++0x's new features? Will the Irrlicht containers use them?

CuteAlien · Post by **CuteAlien** » Wed Apr 02, 2008 9:36 pm

Lol, enough time to think about C++0x. Right now it seems anyway like that will be C++10x. And then add some years until the compilers work perfectly (some don't even support c99 so far...).

MasterGod · Post by **MasterGod** » Wed Apr 02, 2008 9:55 pm

CuteAlien wrote:Lol, enough time to think about C++0x. Right now it seems anyway like that will be C++10x. And then add some years until the compilers work perfectly

Well, the sooner the better

CuteAlien wrote:(some don't even support c99 so far...).

Really? wow..

Saturn · Post by **Saturn** » Wed Apr 02, 2008 10:35 pm

C++0x is probably C++0x0x, so ask again in 8 years.
C++0x features have to wait till all the compilers on the platforms Irrlicht supports also support it. No need to work past reality.

The feature I look forward to the most is std::copy_if btw.

hybrid · Post by **hybrid** » Wed Apr 02, 2008 10:35 pm

Well C++0x features won't be much of a problem, as long as they are not exposed via the user accessible API (because we'd have to create solutions for all compilers and systems in that case, probably completely out of scope). But internals could be optimized with those features, if it makes any sense (which ones would help?).
Oh yeah, and it will probably be C++0xa-f

MasterGod · Post by **MasterGod** » Wed Apr 02, 2008 11:52 pm

hybrid wrote:C++0xa-f

lol, I still hope it gets out in 2009

Regarding the other things, well I guess you are right.

agi_shi · Post by **agi_shi** » Thu Apr 03, 2008 1:59 am

I think of the STL as part of the language (maybe because, well, it is part of the language)

.

One more thing: someone said, "Irrlicht containers are easy to debug" (or something like this) - that's a very ironic statement. The STL was roughly debugged and tested for you already, you will not find a bug in it. So, basically, your statement pwned itself

But, yeah, Irrlicht + STL would be the best. Try posting in "For Beginners" at Gamedev with something like "should I use my own standard library or the STL?"

BTW, I know the discussion sort of died down already, but I just wanted to get my opinion in.

/nullout