This may be a stupid question, but I would like to know if professional C++ programmers use all the STL containers like the stack, list, vectors, etc, instead of creating their own data structures. And also if they tend to use the C++ string instead of the C "string" (array of characters).
Obviously, unless they like wasting lots of time reinventing the wheel...
I've also seen quite a few people who claim to be C++ programmers, but they're really C programmers that also use classes. I call them C+ programmers.
"I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008
"the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010
As a professional C++ programmer what I see is that things such as list, vector, map, set, and string are all used a lot. Not so much queue though.
The only roll-your-own C++ container stuff I tend to come across any more is legacy code from last millenium.
Raw char arrays still tend to be used here and there, but their use is declining.
A year or two ago I used something like a map<list<pair<int, int> >, vector<string> > (with the appropriate typedef's of course).
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
One of the cornerstones of productivity in any programming language is reuse, when that makes sense. That includes reuse of design, reuse of code, or using standard libraries.
Personally, I was using C++ well before the STL existed. For that reason, for a fair while, I had to write my own equivalents of some parts. Most of my older code has since been rewritten - by either myself or successors - to use the STL, although I keep a copy of my original code for reference purposes.
I'd argue that all contemporary C++ programmers should make use of the STL, where it makes sense. That doesn't mean using it slavishly - the decisions about approaches, libraries, etc need to make sense, be justifiable, etc. There are some parts of the STL I have never used, simply because I've never had reason to.
In practice, application writers (as contrasted to, say, library writers) will mostly benefit from using the STL - there will be times they need to write their own equivalents, but those will be relatively rare.
Authors of reusable libraries and frameworks probably have more need to roll their own code, or use libraries other than the STL. If they didn't, it would mean their libraries are duplicating functionality of the STL, so questions need to be asked about why they are writing their library or framework in the first place. Also, if their library provides its own equivalents of STL functionality, that needs to be questioned. For example, if someone writes their own resizable array class, the obvious question to ask is "why not use std::vector?"
I agree with cpjust that a lot of people who claim to use C++ really are using "C with some enhancements that happen to be from C++". Telltale signs of such people include unnecessarily rolling their own libraries (eg a linked list), using malloc() instead of operator new, under-use or overuse of exception handling, avoiding (or overusing) anything template-based (which includes the STL), a preference for macros over function overloading, ..... Unlike cpjust I refer to them as C+/- programmers though
At where I work (game development), the STL is forbidden. They want very tight control over memory use (down to the CPU cache level, with their own memory manager with multiple heaps and stuff to avoid fragmentation), as well as performance certainty across different platforms and implementations.
There's a lot of OOP, including inheritance, virtual functions, polymorphism, and dynamic binding, etc. Just no STL at all.
This is my first job, so I have no idea what is it like outside this little world.
I frequently use STL at work and in production code.
Couldn't they just use STL with custom allocators to control how it allocates memory?Originally Posted by cyberfish
"I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008
"the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010
I didn't make the decision (or was there when they made the decision), so I'm not entirely sure.Couldn't they just use STL with custom allocators to control how it allocates memory?
But I think it's because custom allocators only allow you to specify WHERE to allocate memory from, not WHEN, or HOW (big chunks vs small chunks etc), and it won't give the memory manager enough information for optimization (eg. memory for the same linked list should be close together, but STL won't pass that information to the allocator).
And then different implementations would allocate memory in different ways, at different times, etc, which would result in inconsistent performance across platforms, which they try to minimize. For example, if one implementation of STL has slightly higher memory overhead, it can just push the size of something over the cache line size, and result in huge performance degradation.
Not all STL implementations are equally fast at different things, too. For example, GCC's implementation of std::list doesn't keep track of the length of the list, contrarily to standard recommendation.
Their argument is that keeping the length would make operations like split() O(n), which are more widely used (according to them) than size(), which is now O(n).
So they would have O(n) size() and O(1) split() while some implementations would have O(1) size() and O(n) split().
Both of which are standard compliant, but they sure will create a performance nightmare if you are unaware of it. That's some more inconsistency that can be problematic.
Actually, with careful use, the "STL" allocator design can satisfy all of that. It just requires more care than most programmers are willing to take.But I think it's because custom [...] enough information for optimization.
This is an argument against using different implementation of libraries exporting the same interface. The same argument is equally valid and invalid for all API implementation providers.Not all STL implementations are equally fast at different things, too.
It is a ridiculous argument as they could use the same third-party "STL" implementation on multiple platforms or design their own.
It is equally ridiculous for other libraries. How easily would you swallow "don't use OpenGL" because some platforms may only have a software implementation?
Soma
That's very easy to say. Even I can say it. Example?Actually, with careful use, the "STL" allocator design can satisfy all of that. It just requires more care than most programmers are willing to take.
How do you write an allocator that makes sure std::list allocates 5 blocks at once?
Yes they have designed their own containers. No need to write the whole STL because they don't need it.It is a ridiculous argument as they could use the same third-party "STL" implementation on multiple platforms or design their own.
It applies to all libraries. For OpenGL there is no easy way out, so we have to work with it. For STL there is (writing our own), so we take it.It is equally ridiculous for other libraries. How easily would you swallow "don't use OpenGL" because some platforms may only have a software implementation?
Actually the memory management of the STL is well documented. I would agree that the 'where' of allocation is in question (but can be changed) but the 'when' is absolutely not in question and can be controlled by custom allocators.But I think it's because custom allocators only allow you to specify WHERE to allocate memory
from, not WHEN, or HOW (big chunks vs small chunks etc), and it won't give the memory manager enough information for optimization (eg. memory for the same linked list should be close together, but STL won't pass that information to the allocator).
I know for sure the STL was used in Medal of Honor: Pacific Assault and it did not suffer because of it. I'm sure there are more high performance applications and games that use it without thinking twice. Granted you must be extremely careful about what container you use and what optimizations you employ. I would not, for instance, do a map lookup in every frame but I would iterate the map once and push the pointers in the map to a vector and then render from the vector. When the frame was 'dirty' I would then clear the vector and rebuild it and set the frame to not dirty.
It is my opinion that any issues with the speed of the STL can be overcome by using several types of containers to get the job done. The library is well tested, well documented, and just too much power sitting there waiting to be used to go and spend time writing your own that probably won't be any better than what is already there waiting to be used. But that is just my two cents. I'm well aware of the STL phobias that exist in some studios and others just use it without thinking twice. Granted if you are in the employ of such a company you have to do what you are told regardless of your personal feelings on the matter.
I don't actually know much about allocators since I've never had to use them. I thought it's just providing a malloc-like and a free-like function, and when they are called is up to STL. Am I mistaken?
Even if it's possible, if you were to go that far to make sure STL containers use memory exactly the way you intend it to, wouldn't it be easier to just write your own containers?
Vectors, lists, trees don't sound too difficult compared to the complexity we are talking about here.
If you do all the memory management yourself, exactly how much work is STL doing for you still?
I know our multi-platform engine doesn't use STL, and it's built from ground up in-house (the studio is only a few years old). Most of the people there worked a long time at EA (since we are across the street from an EA studio), so I wouldn't be surprised if it's like that at EA, too (at least at some studios, for some projects), since they are used to it.
From what I hear Valve is much the same way. Remember though these studios cut their teeth on doing everything themselves long before computers were powerful enough to do half of what we are doing today. I would assume some of that do it all mindset is carry over from those times. I'm not saying you can blanketly use the STL or that coding your own custom containers for specific performance minded apps is incorrect but that its usefulness is beginning to wane b/c computers are getting more powerful. But it all depends on your requirements. If this container is only for a specific purpose then I can see that being useful. Most of us I think are used to meeting requirements that usually stress maintainability over performance. In the core code of engines and games I'm not so sure this is true.
IE: Someone has in their sig a statement that says if you make code changes to improve performance by a mere 25% that you would probably be better off just getting a computer that was 25% faster. In a sense that is what has happened and is happening each day.
Nope. I don't really have the time or inclination to masturbate in public just now.Even I can say it. Example?
That was rhetoric. Saying "Don't use an API" because a particular implementation may suck is ridiculous. Your leaders at the job don't know what they are talking about if they say such things.Yes they have designed their own containers. No need to write the whole STL because they don't need it. It applies to all libraries. For OpenGL there is no easy way out, so we have to work with it. For STL there is (writing our own), so we take it.
The company produced their own "STL" implementation and tried to promote it.I wouldn't be surprised if it's like that at EA
(This isn't at all relevant to my point. I just thought you might find it interesting.)
Which is a really stupid thing to say. A new or better computer may buy you a few percent performance over what is, but a new or better algorithm or implementation may buy you a few percent forever.Someone has in their sig a statement that says if you make code changes to improve performance by a mere 25% that you would probably be better off just getting a computer that was 25% faster.
(A better implementation granting the same performance increase as a better machine will likely provide a similar advantage to any future machines.)
Soma
Last edited by phantomotap; 07-25-2010 at 06:14 PM.
Yes, I already know you don't use English grammar when you write in English. What I didn't know is that you don't use English vocabulary either. I will still try to interpret it as English since that's the best I can do as I don't speak the language of monkeys.Nope. I don't really have the time or inclination to masturbate in public just now.
It's like saying solving global warming is easy. Everyone are idiots and doing it the wrong way. You can solve it in one night while watching TV.
But no, you don't have time to do it.
How is that ridiculous?That was rhetoric. Saying "Don't use an API" because a particular implementation may suck is ridiculous. Your leaders at the job don't know what they are talking about if they say such things.
Do you really not get it or are you just trolling?
1.) I never said it's because "a particular implementation may sucK". I said, because implementations are different and not flexible enough.
2.) Even if I did, you are saying we should still use it even if the implementation we are targetting sucks? That's beyond me.
I'm not sure if they know what they are talking about, but I'm pretty sure you don't know what you are talking about, intentionally or not.
