is the STL widely used in professional C++ programming?

This is a discussion on is the STL widely used in professional C++ programming? within the C++ Programming forums, part of the General Programming Boards category; This may be a stupid question, but I would like to know if professional C++ programmers use all the STL ...

  1. #1
    Registered User
    Join Date
    Jul 2010
    Posts
    55

    is the STL widely used in professional C++ programming?

    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).

  2. #2
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    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

  3. #3
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,308
    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"

  4. #4
    Registered User
    Join Date
    Jun 2005
    Posts
    6,636
    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
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Sunshine, and read this, this, and this before posting again.

  5. #5
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    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.

  6. #6
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    I frequently use STL at work and in production code.

  7. #7
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by cyberfish View Post
    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.
    Couldn't they just use STL with custom allocators to control how it allocates memory?
    "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

  8. #8
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    Couldn't they just use STL with custom allocators to control how it allocates memory?
    I didn't make the decision (or was there when they made the decision), so I'm not entirely sure.

    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.

  9. #9
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,409
    But I think it's because custom [...] enough information for optimization.
    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.

    Not all STL implementations are equally fast at different things, too.
    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.

    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

  10. #10
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    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.
    That's very easy to say. Even I can say it. Example?

    How do you write an allocator that makes sure std::list allocates 5 blocks at once?

    It is a ridiculous argument as they could use the same third-party "STL" implementation on multiple platforms or design their own.
    Yes they have designed their own containers. No need to write the whole STL because they don't need 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?
    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.

  11. #11
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    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).
    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.

    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.

  12. #12
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    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.

  13. #13
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    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.

  14. #14
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,409
    Even I can say it. Example?
    Nope. I don't really have the time or inclination to masturbate in public just now.

    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.
    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.

    I wouldn't be surprised if it's like that at EA
    The company produced their own "STL" implementation and tried to promote it.
    (This isn't at all relevant to my point. I just thought you might find it interesting.)



    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.
    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.

    (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 07:14 PM.

  15. #15
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    Nope. I don't really have the time or inclination to masturbate in public just now.
    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.

    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.

    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.
    How is that ridiculous?

    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.

Page 1 of 3 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. C Formatting Using STL
    By ChadJohnson in forum C++ Programming
    Replies: 4
    Last Post: 11-18-2004, 05:52 PM
  2. im extreamly new help
    By rigo305 in forum C++ Programming
    Replies: 27
    Last Post: 04-24-2004, 12:22 AM
  3. STL or no STL
    By codec in forum C++ Programming
    Replies: 7
    Last Post: 04-12-2004, 03:36 PM
  4. Prime Number Generator... Help !?!!
    By Halo in forum C++ Programming
    Replies: 9
    Last Post: 10-20-2003, 08:26 PM
  5. include question
    By Wanted420 in forum C++ Programming
    Replies: 8
    Last Post: 10-17-2003, 04:49 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21