   I am building a cross-platform 3D Game Engine. Is it bad to use STL?
  I am building a cross-platform 3D Game Engine. Is it bad to use STL?I've been building an engine and while it's currently set for PC using DirectX (which I plan to abstract the renderer later to support other graphics API like OpenGL). I'm fond of using STL but I'm not sure if I should depend on it if I plan to do cross-platform. I've been using std::vector, std::map, and std::multimap.Any opinions on this?   
  There is no "STL" (worth mentioning any more). There is the standard C++ library. The name "STL" dates to when people at SGI wrote a bunch of code, most (nearly all) of which eventually ended up in the standard C++ library.That addition happened when the language was standardized. In 1998.This is the standard library of the langauge you are using. Of course it is not bad to use it. If you are not using the standard library, you are effectively not using the language.The standard library is completely cross-platform and its behaviour is thoroughly well documented. That's what's "standard" about it.   ;  I personally think it sucks. It hides a lot of stuff and makes it harder to debug and optimize your code. But then I'm sure many people will disagree. In any case you can write your own containers and iterators in a few days and you will know exactly how they work. You can also customize them for exactly your needs.   ;Quote:Original post by polypterusI personally think it sucks. It hides a lot of stuff and makes it harder to debug and optimize your code.Debugging isn't harder, certainly not with VS2008 which can look into the various containers, as for optimisation; how many times have Std. Library functions come up when you've profiled as the hot spots?Quote:In any case you can write your own containers and iterators in a few days and you will know exactly how they work. You can also customize them for exactly your needs.Which is (a) a few days wasted and (b) unlikely to be as optimal as the current implimentations and likely to contain bugs or problems.   ;Quote:Original post by polypterusI personally think it sucks. It hides a lot of stuff and makes it harder to debug and optimize your code. But then I'm sure many people will disagree. In any case you can write your own containers and iterators in a few days and you will know exactly how they work. You can also customize them for exactly your needs.LOL n00b.   ;Quote:Original post by polypterusIt hides a lot of stuff and makes it harder to debug and optimize your code.I fail to see a problem in optimizing code that uses standard containers. At least you don't have to optimize the container and don't need to look fors bugs in them. You can concentrate on your own code and find bugs and bottlenecks there. The only thing that is hard in the beginning is how to use the containers properly, but that is explained in a lot of tutorials.   ;Quote:Original post by phantomQuote:In any case you can write your own containers and iterators in a few days and you will know exactly how they work. You can also customize them for exactly your needs.Which is (a) a few days wasted and (b) unlikely to be as optimal as the current implimentations and likely to contain bugs or problems.It's not always time wasted, and is often a requirement. SCL containers have large problems when used in conjunction with DLL interfaces - especially plug-in API's. Different STL implementations, different sized containers in debug vs release, different configurations (USE_SECURE_SCL) etc. Basically, if you never use an SCL container in a DLL interface, you'll be OK - otherwise you will need to write your own (which is non trivial to get right).   ;Quote:Original post by OluseyiLOL n00b.Interesting comment coming from staff. Way to back up your argument. Actually I've been programming for a long time. In fact I worked as a programmer for 23 years at intel alone writing tools for IC design. My first compiled language was Fortran 4 and I leaned C from the old K&R book and C++ from Stroustrup. My guess is you are probably far more of a n00b then me.   ;Quote:Original post by polypterusQuote:Original post by OluseyiLOL n00b.Interesting comment coming from staff. Way to back up your argument. Actually I've been programming for a long time. In fact I worked as a programmer for 23 years at intel alone writing tools for IC design. My first compiled language was Fortran 4 and I leaned C from the old K&R book and C++ from Stroustrup. My guess is you are probably far more of a n00b then me.You didn't back up yours. Even now you aren't giving arguments that focus on failures in the SC++L, you are just waving some experience at us.Fair enough, you are experienced. But your experience may not be typical. The thing about the SC++L is that it is a general purpose library - if you had special requirements then maybe the SC++L didn't suit you.Finally, consider that the OP may not be as experienced as you. Maybe you can implement most of the standard containers in a more "optimal" fashion - but can AndreiVictor? Is it going to be worth the investment of time and effort on his part?   ;  So far, the force is strong on PRO-STL. I think I should clarify with what I mean by cross-platform, which is including consoles which don't have swap files like desktop computers would fall into. I'm a very "noob" console programmer and for things like Memory Management which is also just new to me, I plan to override the new and delete operators to a custom memory manager I would make. If I do something like that, would STL comply with the proper use of my new memory allocation scheme? Take note, I haven't done something like this before so, I'm worried about possible repercussions and prepare for them. Just can't imagine how to properly deal with memory fragmentation and how STL would work with something custom such as that. >_<   