Using the C++ STL in graphics engine code?

[cr_itm]

Hello,

this should be an open discussion, I'm looking forward to your opinions. The question is, is it a good idea to use the c++ STL (standard template library) in projects like a graphics engine?

The question came up when I looked through several engines, like irrlicht or the Doom3 SDK. Containers like lists are all custom-implemented and also the std::string class is not used.

From my point of view, there are some things I might using the STL:

- portability
- it's part of the c++ standard
- the code is major (bug free) and optimized on speed


Is there any important point, not to use the STL classes in such a project like a graphics engine?


Thanks for your thoughts

[zenaku]

By irrlicht having it's own implementation, the classes like irrList can be optimized specifically for graphics.

I agree though. For the most part, you'd be better of using the STL whenever possible.

One major drawback would be the dependency on STL itself. You say it's standard, but has it been ported to PSP yet? I know irrlicht has (http://www.irrlicht3d.org/pivot/entry.php?id=348). If irrlicht did depend upon the STL, porting to the PSP would have taken a lot more work.

[jam]

In this thread people examined why Irrlicht does not use STL.

[cr_itm]

One major drawback would be the dependency on STL itself. You say it's standard, but has it been ported to PSP yet? I know irrlicht has (http://www.irrlicht3d.org/pivot/entry.php?id=348). If irrlicht did depend upon the STL, porting to the PSP would have taken a lot more work.

Good point, never thought of that.

In this thread people examined why Irrlicht does not use STL.

Thanks, I'll have a look.

[vitek]

I would be willing to bet that most STL implementations would work on PSP with little or no modification. Like other libraries, they usually provide some sort of config header that changes the features compiled in/out. The Standard C++ Library that I worked on for a while had been ported to several imbedded platforms with only changes to the configuration file.

[Eternl Knight]

While I understand Niko's desire to leave STL out of Irrlicht - I find it is a matter of preference only really. STL is simply a part of the C++ Standard (as has been mentioned by others) and any compiler that does not support it is not C++ Standard compliant. That said, platforms without a compliant C++ compiler are few and far between (and are not likely targets for apps using Irrlicht).

I personally like STL, and find it's speed just dandy in a "game engine". As such, I have a version of Irrlicht that uses STL instead of the Irrlicht supplied template classes. The only thing that needed 'custom' code was:
(a) converting strings between char* & w_char* representations, and
(b) getting a pointer to the data in a std::vector
The rest was simple class / function substitution.

--EK

[zenaku]

While I understand Niko's desire to leave STL out
...
(b) getting a pointer to the data in a std::vector
...
--EK

That's definately not portable! It assumes the data is stored in a pointer, which it most likely is, but not in all cases of STL implementations. std::vector could be a linked list interally. Then there would be no pointer.

[mandrav]

By irrlicht having it's own implementation, the classes like irrList can be optimized specifically for graphics.

Can you please describe how you can "optimize" a list for graphics?

While I understand Niko's desire to leave STL out
...
(b) getting a pointer to the data in a std::vector
...
--EK

That's definately not portable! It assumes the data is stored in a pointer, which it most likely is, but not in all cases of STL implementations. std::vector could be a linked list interally. Then there would be no pointer.

Again, unless I 'm misunderstanding everything, there's nothing more portable. A std::vector is guaranteed to put its contents in consecutive memory locations. It works and feels exactly like a C-array.

Yiannis.

[hybrid]

Well, the description http://www.sgi.com/tech/stl/Vector.html which I frequently use does not impose such an requirement to the implementation. So I'd never rely on that, although most implementations will use some kind of array inside. But you cannot get a pointer to that even if it is used. Vector has some memory handling attributes aside, such that it is not just a C-array, but a class.

[zenaku]

Can you please describe how you can "optimize" a list for graphics?

You have hard coded, optimized versions instead of generic templates. There are lots of things you could do. Think something like a list of matrix4 optimized for SSE/3DNow/etc, or possibly a rendering display list abstracted as an irrList type. You beat the STL in speed by sacrificing code reuse and generic abstractions.

Again, unless I 'm misunderstanding everything, there's nothing more portable. A std::vector is guaranteed to put its contents in consecutive memory locations. It works and feels exactly like a C-array.

If they could do it portably, don't you think it would already be in the standard?

[Eternl Knight]

Actually, this has been clarified in the C++ STL FAQ and other places. Due to the way the std::vector is defined (in terms of the standard requirements), it can be assumed in all cases to be an array underneath. Basically, it can be guaranteed that if vec is a std::vector and it has more than one element:

(&vec[0] + 1) == (&vec[1])


This was clarified in an FAQ, not the standard but is accepted to be "canon". I'll see if I can dig up the reference for you

UPDATE: Reference here.
Note, it is now also mandated in the C++2003 standard that std::vectors are to store their elements in contiguous memory (i.e. an array).
Also Bjarne Stroustrup (the inventor of C++) expressed that it was always the intent here

--EK

[hybrid]

Ah, good to know. I guess this has been a major issue for using self defined data types.

[zenaku]

The great thing about standards is that they always change I've had this exact same argument in the mid 90's. Back then, I was right Thanks for the heads-up EK.

[Spintz]

I'm thinking about writing a DX or OpenGL only version of Irrlicht/IrrSpintz, and using STL with this. I haven't yet decided on whether to use OpenGL or DX yet, I'm noticing that with IrrSpintz, OpenGL has been faster than DX, but I like HLSL more than GLSL at the moment. I have to say though, I'm leaning towards OpenGL.

Anyways, I definitely think STL is the way to go, no more problems with std::string or std::list anymore, so no reason not to use them. You can always use STL for common things and then if you need some kind of special container for matrix or whatever, you can always create it.

[Eternl Knight]

zenaku: Well, you were "by the standard" correct at least. It has been acknowledged by Bjarne Stroustrup that the "contiguous" property of vectors was always what was intended (and just happened to be always what was implemented too!). Still, I used to make the same argument as yourself

Spintz: Personally, I would very much appreciate an OpenGL version only. This keeps the engine cross-platform as much as possible. I have already ditched DirectX (both versions) from my internal STL Irrlicht, but I like the idea of a software renderer for certian things, so I have kept it so far. I have been considering a "GLSL software renderer" for experimental purposes but as it isn't necessary, I haven't put much more than thought into it

--EK