Feedback about STL and irr::core

[AReichl]

> switch to C++11 + STL after v1.9

Very good.
I also would suggest to ditch compiler support below VS2010. There is a book about C++11 features in VS2010, which then would be the "minimum" C++11 features (or switch to VS2015 directly, considering the time the work will take).
I can take care of the CodeBlocks/gcc/MinGW combo.

[CuteAlien]

We already ditched support for compiler below that in svn trunk. Not quite certain yet about which compilers we support ... right now I'm having the trouble that I'm not getting VS 2015 to work in parallel with older VS versions (I can use VS2015 to compile to older platform toolsets, but trying to use the new one fails because somehow the path to the new standard libraries is messed up when other VS versions are installed as well). But this is getting offtopic...

C++11 with threads might have the problem already mentioned - my current set of compilers will probably not yet support it.

[Nadro]

In v1.9 we support VS2010 (mainly for Win XP users...), VS2012, VS2013 and VS2015. I think that in v2.0/v1.10 we should remove VS2010 and VS2012.

[devsh]

As long as you keep compatibility with whatever GCC version the newest CUDA SDK compiler is based off, and use C++x11 in a way that doesn't collide with CUDA.... I dont give a poop!

[polylux]

Agreed, I think aswell it's a good decision. Nice, then I'll be able to range-based crawl over everything!

[REDDemon]

I think the best option would be someting like I did in my toy engine. Use STL but imported in another namespace. That will allow to plugin custom allocators more easily (if someone want ever to do that), you avoid namespace pollution and possibly you reduce breaking changes (if somewhere in the code a method name does not change...).. Having that one extra header gives the chance to decouple from STL later (what if someone want to use EASTL?)

reference:

https://github.com/Darelbi/Bade3D/blob/ ... tdList.hpp

http://www.gamedev.net/page/resources/_ ... roof-r4229

note that what suggested in the article is generally bad practise, it can come usefull in few cases (like this one).

However i think that will be really a major work/change in irrlicht, the smaller the Api will be used to make it easy to change STL later, the greatest the discipline required.

The bad point is that allocators are (my opinion) a flawed concept in STL, EASTL is a good example in that.