Why doesn’t Irrlicht use the STL?
Posted on:March 08 2006
One question I get asked really often is why Irrlicht is not using the STL. I’m going to write a short answer here, and send people the link to this text in the future, or maybe even create a new FAQ entry on irrlicht.sf.net.
Irrlicht uses it's own template containers and does not rely on the STL, the C++ standard template library. In the namespace core, you’ll find several useful templates which I implemented, for example a vector named irr::core::array, a list and a string class. They are written in a way that you should know how they work, if you know how to use the STL, for example they have ::iterators and methods named like ::push_back or ::size(), ::clear(), etc. And they are really fast.
But why all the effort implementing those classes? Simply because Irrlicht is quite portable. Irrlicht compiles with 7 (or even more) different compilers and on 4 different platforms/operating systems, without a single warning. If I would have used the STL, it would have been a bit more difficult to achieve this, and to let Irrlicht keep its performance equally everywhere, because there are so many STL implementations, and all of them differ. Some of them even have bugs, for example the STL which comes with the latest VisualStudio has some known bugs. So I’ve simply a lot less problems by implementing these few simple classes and algorithms. There would have been the possibility to include a STL implementation like STLPort in Irrlicht, but as always, I wanted to reduce dependencies.
Ok, and honestly, another reason for implementing the containers was because I had fun doing that. And I think I did it quite well, the performance of the array is really good and has some really useful methods you don’t find in the STL, same for the string.
Irrlicht uses it's own template containers and does not rely on the STL, the C++ standard template library. In the namespace core, you’ll find several useful templates which I implemented, for example a vector named irr::core::array, a list and a string class. They are written in a way that you should know how they work, if you know how to use the STL, for example they have ::iterators and methods named like ::push_back or ::size(), ::clear(), etc. And they are really fast.
But why all the effort implementing those classes? Simply because Irrlicht is quite portable. Irrlicht compiles with 7 (or even more) different compilers and on 4 different platforms/operating systems, without a single warning. If I would have used the STL, it would have been a bit more difficult to achieve this, and to let Irrlicht keep its performance equally everywhere, because there are so many STL implementations, and all of them differ. Some of them even have bugs, for example the STL which comes with the latest VisualStudio has some known bugs. So I’ve simply a lot less problems by implementing these few simple classes and algorithms. There would have been the possibility to include a STL implementation like STLPort in Irrlicht, but as always, I wanted to reduce dependencies.
Ok, and honestly, another reason for implementing the containers was because I had fun doing that. And I think I did it quite well, the performance of the array is really good and has some really useful methods you don’t find in the STL, same for the string.
Comments:
Baal Cadar
Quote2006-03-09 01:05:00
"and has some really useful methods you don’t find in the STL, same for the string. "
That sums up why I for one am quite glad irrlicht does not use STL. It's easy to add methods to the core classes. If you want to add functionality to a std::string for example it's a little tougher. Also, it's always nice ot be able to look in the source and see exactly how something works.
That sums up why I for one am quite glad irrlicht does not use STL. It's easy to add methods to the core classes. If you want to add functionality to a std::string for example it's a little tougher. Also, it's always nice ot be able to look in the source and see exactly how something works.
Electron
Quote2006-03-09 01:30:00
Ah, thx for the info, I think I'm going to write more of this stuff then. And you are right, maybe it would be an idea to make these classes compatible with the stl algorithms, would be nice.
niko
Quote2006-03-09 08:14:00
It's entirely your decision of course, although I happen to agree with Baal Cadar. I've implemented my fair share of custom containers in the past (most notably before the STL was truly standardised, or well supported), and I don't think any of them were as good as the STL. Maybe you're just better at it than me ;)
One point - many people think the STL is hard to extend, but mostly it's because they're thinking about it the wrong way. To extend the STL you have to understand the underlying philosophy; that extension is by algorithms and functor objects and such, not by subclassing. The STL has a class hierarchy but you're not supposed to extend it, you're supposed to plug your objects into it. It's a little esoteric but there's a hell of a lot of power in there, I highly recommend 'Effective STL' by Scott Meyers to get a peek into this.
One point - many people think the STL is hard to extend, but mostly it's because they're thinking about it the wrong way. To extend the STL you have to understand the underlying philosophy; that extension is by algorithms and functor objects and such, not by subclassing. The STL has a class hierarchy but you're not supposed to extend it, you're supposed to plug your objects into it. It's a little esoteric but there's a hell of a lot of power in there, I highly recommend 'Effective STL' by Scott Meyers to get a peek into this.
steve
Quote2006-03-09 22:37:00
Ehmm, compiles without a warning. Well, sure, under Linux (and probably also for mingw) warnings are turned off. Otherwise (use -Wall) you'll get some 1000 warnings. Maybe you remember my class initialisation patch I sent you about 2 years ago? This would have fixed most of the warnings.
hybrid
Quote2006-03-09 22:54:00
Well, I'm one of the guys that has been asking Niko about the reason for no STL. And while I think he has done a good job on the template container classes - there are areas where they still fall over (which I have mentioned to him). The lack of certian classes has also created (what I would term) bad design choices such as binary sorted arrays where a std::map (or equivalent) class would be much better deployed.
The container classes give me NOTHING that STL doesn't already and there is only one function the Irrlicht string template gives me which is not a standard std::basic_string function (automatic wchar* to char* string conversions) and it took me five minutes to create an STL version. It takes me about an hour all up to convert Irrlicht to STL with negligible runtime speed difference. It also enables me to plug-in a whole variety of third party libraries (both written by myself and others) with alot less "conversion stress". If the Irrlicht containers were STL-compatible (and there wasn't that bloody memory ownership problem) I would likely not have bothered :)
However, like Baal & others, the phrase "Your Library, Your Choice" kicks in. Niko didn't need to give us what he has, so this is not a complaint but (hopefully) a constructive criticism.
--EK
P.S. Compiling my STL Irrlicht does not give me any warnings on Windows or Linux...
The container classes give me NOTHING that STL doesn't already and there is only one function the Irrlicht string template gives me which is not a standard std::basic_string function (automatic wchar* to char* string conversions) and it took me five minutes to create an STL version. It takes me about an hour all up to convert Irrlicht to STL with negligible runtime speed difference. It also enables me to plug-in a whole variety of third party libraries (both written by myself and others) with alot less "conversion stress". If the Irrlicht containers were STL-compatible (and there wasn't that bloody memory ownership problem) I would likely not have bothered :)
However, like Baal & others, the phrase "Your Library, Your Choice" kicks in. Niko didn't need to give us what he has, so this is not a complaint but (hopefully) a constructive criticism.
--EK
P.S. Compiling my STL Irrlicht does not give me any warnings on Windows or Linux...
Eternl Knight
Quote2006-03-10 01:55:00
I was a teaching assistant for a professor teching the second C++ class at my university. I would classify as an "STL Nazi". This is the class were you start learning about classes, operator overloading and other more indepth features of c++ and why it works the way it does.
He had two books for the class, Bjarne Stroustrup's book, and some huge STL book. The first class(and every class there after) he stated word for word "If you can't STL you can't C++). I maid the mistake of "speaking" with him about this statement and philosophy. I am sure many people would see issues with introductory students getting this sort of information but he seed to disagree with me and fired me on the spot. Oh well.
He had two books for the class, Bjarne Stroustrup's book, and some huge STL book. The first class(and every class there after) he stated word for word "If you can't STL you can't C++). I maid the mistake of "speaking" with him about this statement and philosophy. I am sure many people would see issues with introductory students getting this sort of information but he seed to disagree with me and fired me on the spot. Oh well.
TSM
Quote2006-03-10 18:32:00
i think the biggest problem is, that people are afraid of STL. it's so huge and the sources are hard to read. so they implement their own (little and fine) container classes. i did that to. for my current project i'm sticking to STL, but it is really hard to get into it and this is quite frustrating.
maik
Quote2006-03-10 18:45:00
CORRECTION: I mean't to say "I would classify him as an \"STL Nazi\"" in the second sentance of my post.
I am a supporter of many things about STL but I do not think it is a magic pill that is the solution to everything as some people seem to think it is. I think there are some times when one could write a better library in terms of speed, or memory usage, or functionality for there specific project with noticable gains is the aforementioned areas but I belive you would be hard pressed to write a better library and still have the general usability of STL.
I am a supporter of many things about STL but I do not think it is a magic pill that is the solution to everything as some people seem to think it is. I think there are some times when one could write a better library in terms of speed, or memory usage, or functionality for there specific project with noticable gains is the aforementioned areas but I belive you would be hard pressed to write a better library and still have the general usability of STL.
TSM
Quote2006-03-10 19:50:00
Add comment:
|
|
Possible Codes
| Feature | Code |
| Link | [url] www.example.com [/url] |
| Bold | [b]bold text[/b] |
| Quote | [quote]quoted text[/quote] |
| Code | [code]source code[/code] |
Emoticons
 |  |  |  |  |  |  |  |
 |  |  |  |  |
Also the containers are similiar to the STL counter parts, but not in all details, sometimes surprisingly different and with inconsistently named member function (push_back, but getLast). And eventhough they are similiar, they are still incompatible with STL algorithms, which tremendously reduces usability. Java is nice, there is a big standard lib and it is used and respected by almost all projects out there. Not so C++. Every C++ lib out there just *has to* define its own string class, which is never superior to std::basic_string. So, that when you use many libraries for a project at once your backend always contains pointless string conversions from one type to another.
No question: Your library, your choices. Nevertheless this is one of the design choices, I don't understand. Eventhough I can agree with many of your arguments (code readability) I still weight reasons pro STL higher.
The other design choice I don't really understand is that different file types have different interfaces (getXJointNode(), getMS3DJointNode()). If you have time and notion maybe you can explain this too in a blog entry please. I really love this kind of blog entries, as it helps to understand what makes a lib tick, what's the rationale behind it. :)