Not using STL

[Eternl Knight]

heh, well it doesn't need to be VERY portable... only as portable as Irrlicht Now given there is a software shader of pretty decent quality now - that portability has increased in potential, but it is still only a GCC+Linux & MSVC+Windows operation at the moment with possible support for Mac OSX coming up (though that is in question).

As for stating that professional implementations of STL will excel in speed - that is oversimplfying things. Professional implementations tend to optimse for the "average" & "worst case" scenarios.

Please note that I am NOT saying that Irrlicht's templates are better than STL in general. But they might be better for their specialised use within Irrlicht.

As it is, I am already having to "'re-implement" something that I could have just used STL for in my "Irrlicht Editor" extensions. A decent "map" class is not the easiest thing to implement. It's been nigh on a decade since I actually had to WRITE my own red/black binary trees!

--EK

[elander]

I can understand the speed argument. I brought the C++ reference book from Stroutroup (the c++ designer) because most other C++ books are very unreliable. The man itself adverts people to use their own specialized data structures when apropriate however he also recomends to keep the interface compatible in order to use stl algorithms. We can allways test the array data structure against stl vector and benchmark it with different compilers. Most likely we will obtain different performances if we use gcc the latest vc8. But i imagine it wouldn't be that bad. gcc has allways been very good and the latest vc8 offers great support for stl or so they say.

[Baal Cadar]

The man itself adverts people to use their own specialized data structures when apropriate however he also recomends to keep the interface compatible in order to use stl algorithms.

Right. Eventhough the advice is rather vage. But in anyway it doesn't apply to the irrlicht containers IMHO. Cause the interface is not STL compatible and both containers are part of the STL, so not really specialized. core::array as std::vector and and core::list as std::list. More or less like the STL containers, but incompatible to them.

[Eternl Knight]

*laugh* Well, it would appear that Niko's fears are well-founded. MSVC's version of the STL has a memory leak, a relatively large one. Their "solution" at the moment? Recompile & Redistribute the MSVCP80.DLL file!

Which actually affects me now as I will need to check my office code for this and warn my end-users. *grumble*

[Baal Cadar]

I understand what you're saying, and you are right in that regard. But this is no memory leak in the STL implementation. The memory leak is in iostream, which does not belong to the STL.

But it is unbelievable how they could overlook such a gaping error in this important part. The moment you use iostream you are affected. Kinda embarrasing.

[Eternl Knight]

True, "iostream" is not strictly part of the STL, but it is part of the "Standard C++ Library" (even worse if you ask me!). While is is a common mistake to make (apparently), I was incorrect. Apologies

But on that matter - it DOES cut to the point that a "standard" (such as STL & the standard C++ lib) are only standard so far as the implementors make them. Niko has chosen to ensure that the "standard" he uses is under his control which, given this news, is understandable.

People who have been using the "standard" (such as me in my "day job"), now have to do something "non-standard" on Windows machines because MSVC does not implement it correctly. *sigh*

--EK