Why doesn't Irrlicht use STL?

[CuteAlien]

There are times when you have to debug through STL code. It does not happen often, but when you have to you will swear - promised ;-) The reason is usually not a bug, but for example because you need to figure out how things work. Not everything is documented.

Just because beginners should not write their own baseclasses does not mean that experienced programmers should also avoid it. And the fact that something is part of the language also does not matter if you don't need that part and especially not if it can cause trouble in some situations. What matters is only if it makes sense for the project. Like B.Stroustrup said: "I think it essential that a coding standard is tuned to a specific application, organization, or application area."

I want an STL-Irrlicht for the pure selfish reason that it would make me more productive. But that doesn't mean that I don't see the arguments against STL for a 3D lib. Actually you might notice that nearly every 3D lib has it's own set of base classes. Though I suppose that in most cases this is simply because doing that made a lot more sense in the past. I don't think many engine coders which start such a lib today will still do that.

[Dorth]

STL of 2003 is also not the STL of 2008.
Anyway, I can't help but thing agi_shi is right. Denying the STL is like denying templates or new/delete. They are all segments that were added to the c to create the c++. They are vastly known tools that are used in countless libraries, fine tuned by all compilers and questioned by the language committee itself. This is not a library. It's an intrinsic part of the language.

[CuteAlien]

The STL is a library, if it where an " intrinsic part of the language" it would be called STIPOTL :-)

[rogerborg]

It probably depends on whether you consider C++ to be just the syntax, or a complete compliant implementation, as defined unequivocally by the beardy egghead Stroustrup Himself: "[The standard library, of which the STL is just a subset] is something that every implementer must supply so that every programmer can rely on it. [...] The standard library [is] part of every complete C++ implementation."

Claiming that you're programming in C++ but using an incomplete or non compliant implementation of the language is much like losing your virginity with a corpse. It might count, but it's not something you want to put on your resume.

Wild aside: why does Irrlicht include (e.g.) <math.h> instead of <cmath> et al?

[agi_shi]

It probably depends on whether you consider C++ to be just the syntax, or a complete compliant implementation, as defined unequivocally by the beardy egghead Stroustrup Himself: "[The standard library, of which the STL is just a subset] is something that every implementer must supply so that every programmer can rely on it. [...] The standard library [is] part of every complete C++ implementation."

Yeah, this was what I was pretty much trying to get at. It's part of the language, whether one denies this fact is his or her own problem. Like once said, this is like replacing all functions with GOTO statements because the functions will cause too much overhead

Claiming that you're programming in C++ but using an incomplete or non compliant implementation of the language is much like losing your virginity with a corpse. It might count, but it's not something you want to put on your resume.

Heh, good analogy there (hope I used the right word, not the best at engrish terminology)

[CuteAlien]

Denying the STL is like denying templates or new/delete.

That recent Stroustrup interview ( http://www.ddj.com/cpp/207000124?pgno=1 ) is full of gems: "However, for high-reliability, hard-real time code, the simple fact that a new and a throw can't (in general) be guaranteed to execute on a short, fixed, constant time makes them a no-no." So yeah - sometimes it makes even reason to avoid new/delete in c++.

But what I wanted to hint at is that avoiding the STL is rather the norm than the exception in this specific application area (3d engine programming and game programming). So dismissing it like "Try posting in 'For Beginners' at Gamedev with something like 'should I use my own standard library or the STL?'" is a little bit over the top. Don't think I defend the STL usage here I criticize that sort of "it's a clear thing - n00b!!!" argumentation. It's not.

Btw. STL is not the only part of c++ which is typically ignored in games (and also in Irrlicht). Same for rtti (Irrlicht uses for example custom getType() implementations instead) and exceptions. And I also avoid those parts of c++ in my games - and still think of myself as a c++ programmer.

[hybrid]

Wild aside: why does Irrlicht include (e.g.) <math.h> instead of <cmath> et al?

Because it had been that way when I joined the team, and I don't know what is necessary to keep the backward compatibility for very old compilers...

[Dorth]

Code: Select all

      std::vector<type>::iterator pos = v.begin() ;

Code: Select all

   delete [] mPolyCount;
   mPolyCount = new S32[mNumDetails];

2 random finds in tgea:rts

Code: Select all

        typedef std::vector<SubMesh*> SubMeshList;

Code: Select all

		pAffFact = new DirectionRandomiserAffectorFactory();

2 random finds in Ogre3D

So, the first 2 engines I find that are more or less the level of Irrlicht use both. CuteAlien, it's a claim without proof

But what I wanted to hint at is that avoiding the STL is rather the norm than the exception in this specific application area (3d engine programming and game programming)

Back that up please or take it back.

[agi_shi]

...

You know, I tried many times to write out a reply to your post... but it is so completely filled with false info, I didn't know how to formulate my reply.

[MasterGod]

@Dorth: You go girl!

hehe, just kidding.

Well, he does back up what he says.. (Not that everyone else doesn't!!)

[CuteAlien]

So, the first 2 engines I find that are more or less the level of Irrlicht use both. CuteAlien, it's a claim without proof

But what I wanted to hint at is that avoiding the STL is rather the norm than the exception in this specific application area (3d engine programming and game programming)

Back that up please or take it back.

Uhm, actually I was simply talking about the experience I made so far in the game companies and what I know from others what they are using. From the engines I checked myself the time I started with Irrlicht I think Nebula Device, Torque and CrystalSpace didn't use STL and Ogre did use it. But don't nail me on it - that was 2 years ago. Still including Irrlicht that's already 4:1. That's a stupid statistic and I don't doubt that there are many more engines already using STL. But obviously it's no obvious decision. Which is really all I'm saying. I'm all for STL and if someone writes a STL-patchset for Irrlicht with some guarantee that it will be regularly updated when new Irrlicht versions are released, I might even help out on that.

[Dorth]

Heh. But torque is one of the 2 engine I quoted, since I happened to have a copy. I could check out others, but I just thought that since those 2 are the 2 mains we keep being compared to on this forum, they were pretty good values for comparisons. Could get my hands on others if needed though.

[Halifax]

Just curious, but could you get your hand on UE3, CryEngine2, id Tech 5/4, or Insomniac's proprietary engine? It would probably be good to check those out, although I'm pretty sure Insomniac doesn't use STL. They don't even believe in dynamic allocation memory management, especially since they use a shader model.

[CuteAlien]

Garagegames offers lots of engines... tge is not tgea. I have also a copy if it here but don't want to search the CD and install it now. So I simply made a short google query and got that: http://www.garagegames.com/index.php?se ... w&qid=8557

[Dorth]

UE3, yes, the other, I'm not sure. But Irrlicht does NOT have that level of development or money anyway...