Irrlicht and STL

[AutoDMC]

Just a question out of curiosity...

Why doesn't Irrlicht use STL for it's vectors and strings?

I've just been learning STL (I got Dietel's "C++ how to program" and have been reading it), and the author of the book has been singing the STL's praises.

All my previous experience with Vectors and Strings have been part of the APLibrary. APVector and APString. They were OK, I guess.

Irrlicht uses it's own Vector and String libraries, right? And so does TinyXML. And thousands of other projects. Which means if I pass something from Irrlicht into TinyXML, I have to do string conversion, right?

I was just curious as to the decision. I'm gonna try to use STL if it's really worth it in my up-and-coming project (arn't they all?) as a "cross-library-library."

Just wondering?

[AssiDragon]

Why doesn't Irrlicht use STL for it's vectors and strings?

I'd think because STL is not supported by all compilers out-of-the-box, and Irrlicht aims for simple usage. (For many compilers you have to install STLPort in order to use STL.)

Irrlicht uses it's own Vector and String libraries, right? And so does TinyXML.

Not quite... TinyXML can be compiled to not use STL, but it won't use Strings then as I understand, but char* buffers. These two are pretty different things.
Also, you can compile TinyXML to use the STL Strings.

I was just curious as to the decision. I'm gonna try to use STL if it's really worth it in my up-and-coming project (arn't they all?) as a "cross-library-library."

Just wondering?

STL is a very good thing yeah, I'd encourage using it - that said, it's only worth it if you know what are you doing, as STL won't give much help about containers, and using the wrong ones in the wrong places can make serious slow-downs and other irritating effects. But once you learn how to use it, it's pretty darn fast and useful.

You should also note that efficiency of STL implementions vary from compiler to compiler... each has it's own, sometimes good, sometimes not-so-good (for example MSVC compilers prior to NET2003 had a so sucky STL I'm cringing to remember ). So you should also check if your compiler's STL is good enough; or just install STLPort anyway, that's a pretty good thing in both stability and quality.

[Spintz]

STL is not DLL safe in GCC version < 3.0 and Visual Studio version < 7.0

The new Visual Studio .NET and the GCC compilers 3.0 and greater are, but for those who still use older compilers would have many problems with STL across the DLL.

[AssiDragon]

That's what I meant as "not all compilers supporting it". Hell, MSVC 6.0 can't even compile things with it's own STL!

Installing STLPort will fix the problems even with those compilers though.

[niko]

I'd think because STL is not supported by all compilers out-of-the-box, and Irrlicht aims for simple usage. (For many compilers you have to install STLPort in order to use STL.)

Right, that's one reason. The other one is that the STL simply is not debuggable. Ok, it is, but only with a little experience and an eye able to ignore ugly code. In addition, Irrlichts containers have debug breakpoints in case of access violations, which the STL doesn't have.

[AssiDragon]

Right, that's one reason. The other one is that the STL simply is not debuggable. Ok, it is, but only with a little experience and an eye able to ignore ugly code. In addition, Irrlichts containers have debug breakpoints in case of access violations, which the STL doesn't have.

I beg to differ on this one. All the times you get a crash in an STL container, it's usually because your program screws something up - like trying to access something out-of-bound, or trying to use stored but invalid pointers, etc. All these things can be traced back into your code - knowing that crashed inside STL is not neccesary, as the source and cause will be somewhere in your code anyway.

[Spintz]

STL is hard to debug, you have to get a nack for it, understanding the MyVal and Next, Head, etc in Maps, Lists, etc takes a lot of experience to figure out. The new version of Visual Studio ( 2005 ) is exceptionally better at debugging STL, as well as having many, many improvements in STL.

Visual Studio 2005 is also much better at debugging static variables, can't wait for VS 2005!!!

[Guest]

If I understood it correctly Irrlicht uses its own containers so that the implementation is the same across all platforms (as opposed to just the interface)

However, although STL is hard to debug... It was never designed to be good at it. Its just a set of high performance containers, it was written by programmers who work with (or close to) compiler writers who know how to get the most effiency out of it.

The point is you shouldn't have to debug STL there are no bugs in it (or they have gone unnoticed for a VERY long time)

[hybrid]

The point is you shouldn't have to debug STL there are no bugs in it (or they have gone unnoticed for a VERY long time)

I think it should read "debug a program using STL" not "debug STL". If you're using STL you get lots of templates in your code. Most if not all containers come with an additional memory allocation parameter which in turn uses another template based on the first one. Thus even a single string parameter can blow up the debug output to some hundred characters.
But I would never want to miss STL for my projects whatever the debugging pain would be. As soon as I understood the algorithm API my container processing algorithms became really esthetic. And you usually get optimizations for the different vector processing units for free.