Why doesn't Irrlicht use STL?

MasterGod · Post by **MasterGod** » Thu Mar 27, 2008 2:02 pm

I understand that Irrlicht's containers are fast and efficient but are they faster/more efficient then the STL's or is there another reason STL isn't used?

JP · Post by JP » Thu Mar 27, 2008 2:07 pm

I wonder if it's something to do with platform independence... STL works on all platforms but i don't think there's any guarantee how some of the things are implemented. i.e. a vector could be implemented as a list or an array, there's no way of knowing which, so if you want to be sure of how something's implemented, 100% sure, then you'd have to implement it yourself.

Saturn · Post by **Saturn** » Thu Mar 27, 2008 3:11 pm

The STL guarantees a lot, among others it guarantees that vector is implemented as a linear chunk of memory and it makes complexity guarantees for all its algorithms.

You can't say the STL is faster or slower than what Irrlicht does, mainly because the STL is just an interface standard, that has many different implementations and those are of varying quality. Together with a good compiler and many partial template specialisations it is possible to make a very efficient implementation. But how each of the big implementations (Dinkumware, STLport, libstdc++) performs I don't know.
One thing the STL is for sure: more elegant.

At its root though it probably is a NIH syndrome kind of thing.

hybrid · Post by **hybrid** » Thu Mar 27, 2008 3:22 pm

There had been some ideas about implementing an API consistent replacement of the Irrlicht containers with STL on IRC. I guess it's not really what's wanted here, but it would allow all STL enthusiats to use it under the hood also within the engine. Just has to be done...

rogerborg · Post by **rogerborg** » Thu Mar 27, 2008 3:23 pm

JP wrote:STL works on all platforms

XBox? PS3? BREW? Wii? iPhone?

JP · Post by JP » Thu Mar 27, 2008 3:27 pm

xbox? no cos it's poop
ps3? yes cos it's great
brew? yes cos it's alcohol
wii? no cos it's poop
iphone? no cos it's apple
alyson hannigan? no cos she's a skank

God i'm hilarious xD

Well i don't know about xbox, wii or iphone (don't even know what the hell you mean by brew... homebrew related perchance?) but it certainly works on PS3!

I thought that anything that used C++ would have to implement STL... no?

CuteAlien · Post by **CuteAlien** » Thu Mar 27, 2008 5:34 pm

There are sometimes reasons to replace STL (like special needs for memory management which can be very hard to implement using the standard libs), but I suppose the corresponding classes in Irrlicht have more of an historical justification than a technical one.

For new platforms it might sometimes take a while until the standard libs are ported, but with an own implementation that wouldn't be a problem.

I think it would be at least a good idea to try staying close to the stl when adding new features. I was really disappointed when we finally got a map and it turned out to be so completely different that I didn't even manage to port some code which used the std::map.

And while I don't know about it beeing wanted in general - personally I would at least consider giving up a finger for having an Irrlicht using stl ;-) But that's probably just because cutting of a finger is easier to do than to invest the time implementing a stl irrlicht ...

Dorth · Post by **Dorth** » Thu Mar 27, 2008 6:20 pm

Wii, Xbox and iPhone : yes

The STL is part of the c++ standard. Any recent compiler for c++ will have a way or another to access it. No matter, those have one, although I've often seen the same syndrome as Irrlicht on them with game devs, aka, it's not fast enough, let us make ours! Heh, but sometime they have some sort of reason for it, EA's implementation is a good example, with a lot of added functionalities essential for games. But even so, I'd have probably made a compatibly namespace expansion, like stdea or something

Saturn · Post by **Saturn** » Thu Mar 27, 2008 6:46 pm

EA couldn't handle this as an extension because of their own allocators, they can't utilize them with the standard interface, they also extend functionality of the standard containers which wouldn't work with an extension.

Here is an interesting white paper on EASTL discussing the rationale behind their decisions and giving an overview of the interface. A very good read.

BlindSide · Post by **BlindSide** » Thu Mar 27, 2008 6:51 pm

Irrlicht's use of irrAllocator in stuff like std::string allow it to create an instance on the DLL and have it destructed in the app without any heap corruption in MSVC. Thats one logical reason I can think of.

MasterGod · Post by **MasterGod** » Thu Mar 27, 2008 7:47 pm

So it comes down to who's is willing to take the time and do it?

Zeuss · Post by **Zeuss** » Thu Mar 27, 2008 11:09 pm

@JP and confirming Dorth:

C++ is comprised of 2 parts. C++ Syntax/Language and STL. STL is a part of the C++ standard. If there is not an STL implementation then its not technically a C++ standard (ANSI or ISO).

The problems people have pointed at are issues, how STL works and behaves is specified very well but the effectiveness of the implementation varies wildly. The problems are worse when you take into account the common usage of hash_map and hash_set across a lot of C++ implementations but have never been defined in the ISO standard. So the way they work can vary quite wildly, although I have never used them myself.

There are things in irrlichts implementations I like a lot like irr::array's pointer method, but often I find myself defaulting back to stl::vector for functionality I know and can trust.

JP · Post by JP » Fri Mar 28, 2008 8:45 am

yeah i'm obsessed with the STL vectors... use them for loads of stuff and in fact probably use them when i probably shouldn't

BlindSide · Post by **BlindSide** » Fri Mar 28, 2008 11:05 am

Well believe it or not, I first familiarized myself with containers the Irrlicht way, so I trust irr::array, core::string and core::map alot more than their STL counterparts, more so because the code is right there for me to see and I know the implementation isn't going to change whereever I go.

I really don't recommend putting any STL inside Irrlicht, that would be a waste for whoever worked hard to make these custom containers and functions that emulate the STL. Instead, I think we should just put STL-style functions into Irrlicht containers if we find them lacking, eg:
http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=26985

Cheers

bitplane · Post by **bitplane** » Fri Mar 28, 2008 12:25 pm

BlindSide wrote:I really don't recommend putting any STL inside Irrlicht, that would be a waste for whoever worked hard to make these custom containers and functions that emulate the STL.

I'm pretty sure that's a bad reason not to change, it would be like arguing against motor vehicles because of the thousands of years spent developing horse and cart technology.
The original reason for Irrlicht having it's own arrays and lists was because VC6 had some show-stopping STL bugs. The argument against should be because of the effort of making the change and any loss of functionality it would cause, simplifying the implementation code is a positive not a negative.