Why doesn't Irrlicht use STL?

BlindSide · Post by **BlindSide** » Fri Mar 28, 2008 12:51 pm

But we still have similar problems with MSVC 2005. For example, if a string is allocated using the standard allocator in the Irrlicht DLL, and then passed to the application and destructed, it would cause heap corruption. Irrlicht's container templates allow definition of a custom allocator (irrAllocator in this case) that can circumvent this issue.

We will also be losing all the pretty "irr::"'s and stuff, I personally think STL syntax looks ugly compared to the Irrlicht ones, especially the documentation and ease of use. For example using "erase" on an Irrlicht array is simply a matter of supplying an index number, whereas std::vector requires a .begin + the input number. I know this isn't difficult for anyone totally familiar with the STL, but it can get confusing for beginners.

Also, here is the help info comparison for the function "push_back":

std::vector:

void std::vector<_Ty,_Ax>::push_back(const _Ty &_Val)

core::array:

//! Adds an element at back of array. If the array is too small to
//! add this new element it is made bigger.
//! \param element: Element to add at the back of the array.

And whats with all the function/parameter names starting with an underscore? Its ugly I tell yah.

Yes, yes, it's blaspheme to speak against the STL, and most STL implementations are guaranteed to be entirely stable and probably the fastest possible method of achieving what is required. But I can't help but feel we are polluting Irrlicht if we begin to introduce it into the source code, especially if it is presented in the interface.

Saturn · Post by **Saturn** » Fri Mar 28, 2008 1:51 pm

BlindSide, you don't have these DLL boundary problems with the STL as long as STL is included as a shared lib, which is default anyway. Your MSVC2005 problem is likely a project misconfiguration. I happily create/move/destroy STL objects over multiple DLLs without a problem.

Whether STL looks more or less ugly lies in the eye of the beholder, but many (if not most) C++ developers are familiar with the STL. Syntax differences between STL and irrlicht containers are slim at best and I prefer external algorithms over internally implemented as long as there is no advatage of internalising them. Internal search in irr::core::array is not faster than std::find, but search has to be implemented for each container anew, while a single std::find implementation serves all containers. Actually irr::core::list doesn't even implement a search. STL not only has std::find, to find an exact match (according to operator==), but also an std::find_if to find one with a certain criterion and many more.
So with N algorithms and M containers you'd have to write N*M functions with internal irrlicht style, and only N functions in STL style. (A bit simplified, but in principle this is how it works.)

That said: You probably can already use STL algorithms with irr::core::list, because from the looks of it list's iterator is a bidirectional iterator model.

We will also be losing all the pretty "irr::"'s and stuff, I personally think STL syntax looks ugly compared to the Irrlicht ones, especially the documentation and ease of use. For example using "erase" on an Irrlicht array is simply a matter of supplying an index number, whereas std::vector requires a .begin + the input number. I know this isn't difficult for anyone totally familiar with the STL, but it can get confusing for beginners.

You know what's even more confusing?
That irr::core::array::erase works with an index, irr::core::list::erase works with an iterator and irr:core::map doesn't even have an erase but calls it remove.

And whats with all the function/parameter names starting with an underscore? Its ugly I tell yah.

What function starts with an underscore? And who cares whether parameters start with it.
If you need an STL api reference, take this one for instance.

wyrmmage · Post by **wyrmmage** » Sat Mar 29, 2008 12:24 am

I haven't used Irrlicht for too long, but I would think that the STL should not be used, simply because we can customize the containers that Irrlicht uses to its needs, which could be more features or more speed. It's hard to do this with the STL, because it was built to be useful in many different types of projects.

-wyrmmage

Saturn · Post by **Saturn** » Sat Mar 29, 2008 12:31 am

And what would these needs be? Right now Irrlicht's containers do nothing more and nothing better than STL does.

wyrmmage · Post by **wyrmmage** » Sat Mar 29, 2008 1:48 am

true, they don't; I'm just saying that at some point in time, we might want to add functionality (and I don't know what that functionality would be, I'm just anticipating something that could be useful in the future

). I still don't see why people want to change it to using STL...really, what's the point?
-wyrmmage

BlindSide · Post by **BlindSide** » Sat Mar 29, 2008 2:17 am

Yeah I really don't get the point myself. You can use std::find and std::sort with Irrlicht containers right? They implement the necessary operators.

Saturn wrote: You know what's even more confusing?
That irr::core::array::erase works with an index, irr::core::list::erase works with an iterator and irr:core::map doesn't even have an erase but calls it remove.

Well the very fact that we are using our own containers means that can be improved. Besides I'm sure all lists require iterators to index.

This really isn't so much a technical point I am trying to make as trying to re-awake everyone's "independent Irrlicht spirit"!

Dorth · Post by **Dorth** » Sun Mar 30, 2008 7:03 am

Being independent for being independent is just plain dumb. Let's all code back a new language while we're at it! Irrlicht is a graphic engine, not a language extension. Where's Rogerborg with his "If you don't need it" when you need it. Anyway, right now the score is:

STL can do more than Irrlicht's implementation
STL is available anywhere Irrlicht is
STL is part of the language and thus everyone know or should know how to use it.
STL is extremely optimized in average, likely so more than Irrlicht
We do not need nor plan to need anything that the STL would prevent us to use.
Other libraries floating around use STL, not Irrlicht's implementation.

So let's do the right move and switch to it? There are NO penalty right now other than the time needed to switch back. But the cost might grow with time, as with any design mistake. Let's be kind to our project here and now and make sure it'll be around in good shape in 5 years.

Halifax · Post by **Halifax** » Sun Mar 30, 2008 7:20 am

If you want STL, then I would go to the 3D engine next door. I have to agree with BlindSide, and wyrmmage, on the fact that we should keep the Irrlicht containers.

Honestly it comes down to this. What if a new super-duper 50 core processor is made, and STL runs functions in a general ~2,000,000 cycles, which is horribly unoptimized because it doesn't take advantage of the 50 cores. Well with Irrlicht containers you have the source code right in front of you, so you can optimize it for the cache/memory alignment/cores/whatever and then use it, and look, you optimized it down to ~2,000 cycles.

This fact was even shown in real life, when Intel created a multi-core optimzied version of STL containers. This means that STL isn't best in every case, otherwise there would have been no need for this. So with Irrlicht containers we can write our own multi-core versions if need be.

That is an extreme example of why we should keep them. Being independent for the sake of being independent is not dumb and it has been proven in companies across the board from Capcom, who made their own physics engine from scratch just to have it in-house, Rockstar, and Insomniac Games.

Keep the Irrlicht containers!

Dorth · Post by **Dorth** » Sun Mar 30, 2008 9:04 pm

And you really think that at any point in time, WE who have 3-4 active devs with far too much stuff to do, lagging behind in all 3d fields and portability will somehow manage to do an extremely optimized version of STL portable before the compilers Irrlicht is compatible with do? You're kidding yourself.

MasterGod · Post by **MasterGod** » Sun Mar 30, 2008 9:24 pm

Dorth wrote:And you really think that at any point in time, WE who have 3-4 active devs with far too much stuff to do, lagging behind in all 3d fields and portability will somehow manage to do an extremely optimized version of STL portable before the compilers Irrlicht is compatible with do? You're kidding yourself.

That's one way to put it

But since we're at it, nevertheless if they would or not, which side of the argument do you choose?
Do you think STL does better job then the Irrlicht containers?

Halifax · Post by **Halifax** » Sun Mar 30, 2008 10:33 pm

Dorth wrote:And you really think that at any point in time, WE who have 3-4 active devs with far too much stuff to do, lagging behind in all 3d fields and portability will somehow manage to do an extremely optimized version of STL portable before the compilers Irrlicht is compatible with do? You're kidding yourself.

I'm not saying the developers will, I am saying the advanced users may! Of course the developers are developing for those super-duper processors, but the users may be, and they should have all the code at their fingertips to manipulate it.

In fact, the PS3 compiler was crap at the start, so I'm sure if someone was to release a lanuch title with the use of STL it would have sucked a lot since so many optimizations can be made for the PS3 since it contains non-scalar SPUs. (STL doesn't take advantage of platform-specific optimizations such as vector processing, DMA, caching, etc.)

The point is, the STL source is not readily available, and pretty horrible to edit; furthermore, the Irrlicht source is readily available, and is coded in the same style as the rest of the engine.

BlindSide · Post by **BlindSide** » Mon Mar 31, 2008 1:32 am

Well we could add duplicate methods identical to the stl versions, then if someone wants to exchange say core::array in an existing project for the STL version, they can just do:

Code: Select all

typedef std::vector core::array;

Halifax · Post by **Halifax** » Mon Mar 31, 2008 2:06 am

Exactly, there is no problems with what BlindSide says. It produces more features for Irrlicht, and allows more customization.

Dorth · Post by **Dorth** » Mon Mar 31, 2008 2:29 am

Halifax, what you wrote is false. There isn't a central implementation of STL. Only a central standard. Every compiler out there fight to have one of the best implementation. STL IS optimized per platform, that's the goal of each compiler. If the compiler for PS3 was really crap, then anything compiled with it would be crap, not truly optimized, unless you go in machine code. Right now, Irrlicht is not even compatible with STL. Tell me you know the inner workings of the core::list for kicks. Using a standard assure compatibility, understandability, portability. Going against it without a clear reason takes time, increase risks of problems and add an unnecessary workload on developers. You need something of the STL changed? Good, do it on your project. Most compiler have an option to change the STL implementation used. Also, in most case, you can just plug and play your code. This is a public graphic engine, not a language library or private development with one project or two depending on it. If you want to change the STANDARD of the LANGUAGE, bring friggin good arguments to the table.

Zeuss · Post by **Zeuss** » Mon Mar 31, 2008 3:36 am

I think I am going to have to agree with the pro STL'ers in this argu... discussion

It just makes more sense, it is the standard for containers so why reinvent the wheel? It has sets of standards to do its job that every C++ programmer should know, and these standards are implemented

But I know the problems attached with this, the first off is it is major api breaking change and secondly it could be a lot of work to change it, but it is just tedious work to change.

I would be willing to try it.