Not using STL

[elander]

In the coding requirements section of the faq it says not to use stl. What is the problem with stl ? Can someone give me an example ?

[dhenton9000]

Try compiling crazy eddies gui for Irrlicht and Orge, the dependencies and requrements for different versions of STL are astounding.

[elander]

Maybe that's why they call him crazy.

Now really there is for example stlport which advertises:

"Multiplatform C++ Standard Library (STL implementation). Many compilers and operational environments supported. Standard (ISO/IEC 14882) compliance. Maximum efficiency. Exception and thread safety. Debug mode."

and is open-source. It looks like a good choice. But if you use windows stl then you will be in trouble with dependencies.

[disanti]

Stlport is poop for one good reason: external dependency bloatware...
Take Ogre3d for a good example, it requires about 30 different dlls because the programmers ask the same question as you (oh why not use stlport? oh why not use DevIL?).

Let us keep Irrlicht in one piece.
________
Ferrari f1/87

[elander]

I never requested to put stlport in irrlicht im just trying to understand the decisions. Plus asking questions doesn't hurt anyone it's the wrong answers and lack of objective criticism that usually cause people to choose badly.

Ogre is a problem but not because it uses too many external apis or because it offers too many features. It's a problem of the api interface that is unecessarily complex and doens't hide that complexity from the user.

Can you say anything concrete about how stlport is bloated or are you just spreading rumors and fears? I have stlport source in front of my eyes and upon a close examination i only see dependencies on the c standard library and either windows 32 api or gclib (depending on the platform) and this is because of the locale that needs to query the os it is running on about locale settings. You take away locale support and your only dependencies are c std. Or edit the c_locale_win32.c file and replace it for your own settings but then you can't query the os unless you access its api.

"(oh why not use stlport? oh why not use DevIL?)."

Afraid of dlls? DevIL, stlport and even SDL have been successfuly ported and used with consoles and different platforms like macosx and linux. Again i don't see the big advantage in having everything compiled into a single dll except to make distribution easier.

Sure Ogre is big and you can't deliver a crappy tiny demo with it without it explode to several tens of megabytes, but this is mostly the size of Ogre itself and the xerces api. They could do much better if they want to. They could use only a sax processor and get away with the validation part of xerces and they could greatly simplify Ogre interface to make more user friendly. Don't blame external apis for the way they are thrown in Ogre without any criterium.

[dhenton9000]

One thing that is really cool about irrlicht is that it is a stellar example of good software design-- matching implementation to design goals.

I'm only guessing, but I think one of Niko's design goals was controlability, meaning keeping Irrlicht maintainable, and I think that includes keeping it free from being strangled by dependencies.

I can see an advantage to STL stuff, but I can't see any advantage to some STL port over and above what's in Irrlicht now. The distadvantages of an external dependency on STL outweigh any advantage in this case because the needed functionality is already there. I think that's by design.

Better to create your own devils that deal with someone else's.

[Eternl Knight]

I'm of two minds over the whole "keep STL out" requirement of Irrlicht. I wind up agreeing with Niko for reasons of maintainability more than anything else, but I'll outline both sides as I see it.

Firstly, I am a big fan of STL in general. I use it in pretty much all my "business application" projects and would be incredibly hampered in developing my "number crunching" applications without it. That said, there are two problems with it - first there is the cross-platform / deployment issues when developing cross-platform and there is the "code bloat" that can occur.

With cross-platform development, most the common features of the STL are fine (especially now with M$'s current compilers). However, some of the more esoteric stuff does differ from platform to platform unless one uses STLPort (a great project). Which, of course, brings up the deployment issue. I frequently have to provide source code for the projects I write (part and parcel of most our development contracts), with instructions on how to compile it on the target platforms. When the project is cross-platform and/or the development environments can differ drastically (such as on diffent distros of Linux) - external dependancies can become a problem. Often it is unavoidable, but where possible it is nice to avoid it. I think Irrlicht is one such project. I can currently download, unzip, and start development on a new version safe in the knowledge that everything comes under the same conditions as the Irrlicht license (or better).

As with the "code bloat" this is a combination of two things: unnecessary features compiled in and compiler optimisation (or lack thereof) of templated classes. STL is full of unnecessary features for most projects as it covers pretty much every concievable use of it's classes. When compiling an executable sith statically linked libraries - the extra code related to these features can be trimmed out with some compiler setting tweaks. However, Irrlicht is compiled as a dynamically linked library. And as such, the "extra" features are kept in because someone MAY use them. Combine this with the fact that some compilers will not "collate" like template classes in the machine (meaning there may be two or three implementations of "array<CFooClass>" with all it's iterators and whatnot depending on the compiler and how the project is built) - this can add up to larger deployments than desired. I personally am not too bothered by the amount this could/would increase my executables/libraries but there are others using Irrlicht catering for the lowest common denominator in terms of Internet user / game player. They need to think about those people with dialups and slower computers with less memory.

All in all, the biggest advantage of NOT relying on STL & so on is the fact that Irrlicht is much more maintainable being a self-contained package. As I said earlier, it is possible to download Irrlicht and get to work on something immediately. Deploying is just as easy. Those worried about "code bloat" are also covered by the fact that Niko's templates are short and to the point. There is not a feature in there that he DOESN'T use - no iterators, special-case algorithms, etc. YOU as the end user are free to use whatever you like in the end product (I use RakNet & SQL-Lite for example). what Irrlicht provides is a self-contained package that we can all use without worrying about any of the above

--EK

[Guest]

I'm afraid this thread is rather indicative of the experience level of most people here.

Modern software design is about reuse, not reinvention. Reinventing everything yourself because you don't trust other people's code is a habit for lone programmers with too much time on their hands, not for serious software engineers who work in teams, not on their own.

Relying on existing libraries for existing functionality is completely normal. It's also rather hypocritical for what is actually a library project to say external libraries is bad.

The downside to not using the STL is that you don't get to use the huge amount of power and familiar patterns that it represents. All C++ coders worth their salt know the STL well and hence if they come to a library that uses it, they immediately know how these things work and how to extend them, and what the performance characteristics are. If everyone writes their own containers, iterators, sort algorithms you end up with 100 different implementations of the same thing, all with different APIs, which is a complete waste of time and effort. Something this fundamental, proven and common doesn't need to be reinvented. The fact that you think it does shows a lack of real-world experience in my view.

[Dark Rain]

Well, the only real argument agaisn't the vanilla STL is problems with say a non standard hash maps or incomplete stl implementation. Incomplete stl implementations aren't a problem anymore on most platforms I imagine. Of course, this doesn't really apply here =). If it were to use the STL, I imagine non standard features would just be banned from being used.

[Baal Cadar]

I don't agree at all, that STL is another dependency. It isn't. It is part of the C++ standard, like the Standard C lib was of a part of C. Its behavior is well defined and implemented accordingly by todays compilers. STLPort != STL, it is just an implementation of the STL + a few extras (like hash_map). There is no portability issue as long as you stick to the standardised STL.

I also wondered about this STL ban in the code guidelines. IMHO implementing your own containers in C++ is pointless, unless you have specific needs, the standard containers don't provide. But this is not the case for irrlicht's containers. In my book the comparison is that irrlicht's containers provide nothing, the STL doesn't. And you loose flexibility. STL is not only containers, but also algorithms and iterators basically glueing the two together. Since core::array doesn't provide iterators and I am not sure if core::list iterators are a model of STL iterators, I cannot use the STL algorithms. The strength of STL is how all the little parts work together.

To me it seems to be the old "Not invented here" problem, where one wants all control over the code, "what I didn't write can't probably be any good."
STL implementations are written by people who know what they're doing. They are specialists on this terrain and know all the aspects that are to it better than 3d programmers do, probably. It's their job. So performance is surely no reason for self-rolled containers. STL implementations are at least equal, probably better in that regard. Maintainability can't be a reason either. Since you now have more code to worry about and more code to put errors into.

STL, as part of C++, should be known by all experienced C++ developers. Using STL in your library means, you don't have to remember yet another container system, but can use your already known knowledge. It is easier to port portions of older code too this way. This is the whole reason to have a standard in the first place. Writing your own containers is ignorance to this standard, imho.

Same goes for strings, btw, though they basically are containers too. Yet again one has to do a pointless conversion between std::string in the backend and core::string, if you have to pass something to irrlicht. This is so annoying.

elander, a small correction: Ogre doesn't use xerces, older cegui versions do. Ogre uses a built-in tinyxml for its own parsing. Xerces was only delivered for cegui and the most recent version doesn't anymore, since cegui now can also use its tinyxml parsing.

[Eternl Knight]

Right... did you actually READ my post? Did you note that I use STL almost constantly? Did you note the reasons that I think Niko has it right for this project have nothing to do with "trusting other people's code" and everything to do with maintainability across platforms, code-bloat, & deployment issues?

I make a living from code development and have done so now for almost ten years. I've worked in teams and alone on projects ranging from single-user data-entry applications up to client/server application suites with well over five hundred simultaneous users processing and presenting maps & property information. I think I can honestly say I have enough "real world experience" to comment on this from an educated perspective.

I don't think allowing STL would be a bad thing, but I also think that not putting it in there is a good thing. One has to remember that the STL does not give you the "fastest possible" implementation of a data structure like a vector or hash-map. It's guarantees are usually about "worst-case" scenarios. And you know what - converting from Irrlicht arrays to STL vectors is a piece of cake, allowing you to use all those STL algorithms as needed. As you said - Irrlicht is a library. So long as it's interface is maintained - who cares what is underneath?

--EK

[disanti]

I wasn't saying that STL was another dependency, I was saying that STL-port was... I figure that using STL-port in these days is completely pointless now that just about all the common compilers out there handle STL just fine.

I myself use STL a lot in my programming, but for Irrlicht, I believe that STL should be kept out as it already has its own routines.
________
SUZUKI RF SERIES

[Baal Cadar]

Errm, eventhough I don't believe you comment on me but on the guest, and I didn't really comment on your points before, but just said my general thoughts on the topic. I have now a few comments.

Did you note the reasons that I think Niko has it right for this project have nothing to do with "trusting other people's code" and everything to do with maintainability across platforms, code-bloat, & deployment issues?

While I don't know the reason for this decision (other than the few points mentioned in the API docs), I am very curious about it. Nico, if you like to comment on this topic, I'd be glad.
I don't see how using STL affects any of these points. STL is multiplatform and the standard part of it is, well, standard. It is the same in any implementation on any platform. It hasn't been always the case, but for at least four, five years this is true. There is no "code-bloat" either, as only the parts are linked/embedded, that are actually used, and code-bloat is not really an issue anyway imho. Deployment goes with the first point.

One has to remember that the STL does not give you the "fastest possible" implementation of a data structure like a vector or hash-map. It's guarantees are usually about "worst-case" scenarios.

The complexity of the operations on the containers are defined in the standard. The irrlicht classes have the same complexities, as they are implementation inherent in this case. But there's more to performance than just this. It's fine-tuning. And in that regard STL implementations are probably better. Partial template specialisation is a tool for doing this, for instance. This probably doesn't matter for these simple containers. It is more important for the ones not provided by irrlicht.

And you know what - converting from Irrlicht arrays to STL vectors is a piece of cake, allowing you to use all those STL algorithms as needed. As you said - Irrlicht is a library. So long as it's interface is maintained - who cares what is underneath?

Actually I don't see an easy way to convert one to the other. Only copying. Casting the array itself won't work and casting pointers to vector::iterator is not safe either, as you had to care what's underneath for that.
The fastest safe way I see, is creating a vector of the wanted size and then copying using memcpy or something like this, and even this is rather ugly. What way do you propose?

[Eternl Knight]

I was commenting to "Guest" actually, but I'll answer your points as technical discussions help & enlighten everyone

The complexity of the operations on the containers are defined in the standard.

Quite true, but only in terms of O(1), O(N), O(logN), O(N^2), etc. The "constant" & "linear" times are not necessarily the best possible for a given situation. I can write two different algorithms, both of them O(N) in complexity that take a completely different amount of time to run.

Casting the array itself won't work and casting pointers to vector::iterator is not safe either, as you had to care what's underneath for that. The fastest safe way I see, is creating a vector of the wanted size and then copying using memcpy or something like this, and even this is rather ugly. What way do you propose?

Actually, most the commonly used algorithms in the STL will work with a simple array (i.e. pointer to memory buffer). This is a fact I use all the time in my business code as I commonly work with "hardware interfaces" that communicate via a memory buffer. But the copy method was actually what I was talking about (yes, even the memcpy one). As you mention though - the "big deal" isn't (or shouldn't be) about the existing data structures in Irrlicht but the ones in STL that we don't have...

As for the code-bloat thing, as I said in my earlier post, this does not bother me, but it might bother others. Especially given the fact that not all compilers will "collect" the instantiations of "core::array<CFoo>" and have them all use the same machine code. For some developers, every little bit of "fat" they can trim off their executable is a "good thing". Unlike an application executable, Irrlicht MUST compile in all the functions of a templated class as they MAY be used by the library user. Making a statically linked version of Irrlicht (a simple task) would fix this of course.

To prove the point - you can create a class with several functions defined but not implemented. So long as the functions are never called - the linker will not raise a fuss about them in an "application". Now expose this class to the external world through a DLL project, suddenly those unused functions become necessary as the user of the DLL "may" decide to use the functions even if you don't. This is what causes "code-bloat" when using STL in a DLL as there are alot of functions available for some STL containers. Not a big deal for some, but it is for others.

--EK

[Baal Cadar]

Quite true, but only in terms of O(1), O(N), O(logN), O(N^2), etc. The "constant" & "linear" times are not necessarily the best possible for a given situation. I can write two different algorithms, both of them O(N) in complexity that take a completely different amount of time to run.

Exactly what I was talking about. Professional STL implementations excel here. There is not much air in array and list for much improvement probably, but if they aren't equal performancewise, then I believe STLPort or Dinkumware to be faster.

Actually, most the commonly used algorithms in the STL will work with a simple array (i.e. pointer to memory buffer). This is a fact I use all the time in my business code as I commonly work with "hardware interfaces" that communicate via a memory buffer.

While this is true for most STL implementations, it is not guaranteed by the C++ standard. It is implementation defined. This works fine as long as you stick to implementations that use pointers as vector iterators, but is not very portable.