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; But no, you don't have time to do it. Correct. Writing 4000 lines of dense boilerplate to show a newbie ...

  1. #16
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,256
    But no, you don't have time to do it.
    Correct.

    Writing 4000 lines of dense boilerplate to show a newbie and his bosses how to do their job just to prove that I know how to do it, i.e. doing it in a public forum without getting paid, is public masturbation.

    You can solve it in one night while watching TV.
    Correct.

    Given the time and inclination anyone who has completed every exercise in, for example, "The C++ Standard Library" can accomplish what you've asked without difficulty.

    I said, because implementations are different and not flexible enough.
    Correct.

    You said "because implementations are different" do not target a particular interface.

    You are saying we should still use it even if the implementation we are targetting sucks?
    Incorrect.

    I'm mocking you and your bosses confusion of interface and implementation.

    Soma

  2. #17
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    Writing 4000 lines of dense boilerplate to show a newbie and his bosses how to do their job just to prove that I know how to do it, i.e. doing it in a public forum without getting paid, is public masturbation.
    I can assure you, our implementation of linked list is less than 4000 lines .

    Keep mocking. I am moving on.

  3. #18
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    You shouldn't take hyperbole literally.

    Anyway, I'm pretty sure that EA's STL implementation played a very important role in the development of C++0x's scoped allocators.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  4. #19
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by phantomotap View Post
    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
    I think the point of that saying is that it's faster & cheaper to buy a faster system than to optimize it right now, just so they can finish it and start making some money sooner. Later they can go ahead and optimize it if they need to, but getting something out the door as soon as possible is usually the most important thing to companies.
    "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

  5. #20
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,596
    Now that is ridiculous. Then every gamer who buys it has to suffer instead.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #21
    Registered User
    Join Date
    Jun 2005
    Posts
    6,290
    Quote Originally Posted by cyberfish View Post
    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?
    That is sort of correct. The allocator also provides functions for constructing objects from that memory.

    The default-supplied allocators (i.e. the ones used by standard containers unless you tell them to do differently) essentially just provide dynamic allocation of raw memory. Functionally, that is equivalent to malloc() and free().

    User supplied allocators obtain memory from other places (eg from shared memory, via some other API, etc). However, they provide the same style interface.
    Quote Originally Posted by cyberfish View Post
    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?
    Maybe. You'd need to specify the functional requirements your container is required to meet, and the constraints in which it is required to meet them.

    In particular, you need to provide an objective justification for using memory in "exactly the way you intend to". What benefits are you seeking, and what trade-offs are you accepting that make your container preferable to the STL containers?
    Quote Originally Posted by cyberfish View Post
    If you do all the memory management yourself, exactly how much work is STL doing for you still?
    The STL containers do the memory management they need using the allocator. The allocator acts as the intermediary to raw memory.

    The entire purpose of an allocator type is (in your words) to allow control over WHERE (e.g. from shared memory or a database) and HOW (eg. by what API) raw memory is allocated. The container type itself controls WHEN memory is requested and the QUANTITY asked for in each request.

    The different types of strategies used by different containers represent different functional and non-functional trade-offs (eg allocation strategy).

    Each allocator type is required to provide a defined interface by which each container may make its requests for raw memory, and for initialisation of that raw memory (i.e. construction of elements)

    Quote Originally Posted by cyberfish View Post
    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 your comments, the message I am receiving is that your developers are either working with a "not invented here" mentality, or have simply stuck with an in-house approach due to lack of understanding of what the STL actually allows them to do.

    Neither is a valid reason to exclude the STL (and, equally, not a valid reason to use it). Choosing between an established in-house approach and a standard library requires an informed comparison of the two. In other words, a list of specific functional and non-functional requirements against which both approaches may be compared.
    Quote Originally Posted by cyberfish View Post
    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?
    You wouldn't. An allocator is not the place to enforce such a constraint. That is in line with what I said above: it is the container that decides when it makes a request of the allocator and, when it does, how much it requests.

    Such a restriction (allocating 5 blocks at once) would also be less efficient by various objective measures than the default strategy used by most std::list implementations, which doubles the buffer size every time a new allocation is requested. (That default behaviour gives a linear execution time - which is required by the standard - for single appending or insertion of elements into the list. I suspect allocating five blocks at once would not meet that requirement.).

    How about you explain what the purpose would be in limiting a linked-list-style container (or any other container, for that matter) to allocating five blocks at a time? In particular, clarify the circumstances and measures by which such a constraint is considered most or less effective/efficient/whatever than any of the standard containers.

    I'm curious to know how that container would behave if you attempted to add six (or more) elements to it.

    The reason I ask is that I'm curious to know the circumstances in which I would prefer your in-house containers over the STL. Or vice versa. Assume in your response that, I'm not obligated by any policy to use either your in-house containers or the STL containers.

    My concern is that I look at the "five blocks at once" as an implementation choice, and can't see what functional (or non-functional) requirement it would actually address.
    Right 98% of the time, and don't care about the other 3%.

  7. #22
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,256
    Such a restriction (allocating 5 blocks at once) [...] meet that requirement.).
    O_o

    That may be the implementation strategy used by `std::vector<???>' to achieve the necessary time requirements. Any insertion into a `std::vector<???>' may invalidate all outstanding iterators. It isn't a bad practice to double the buffer and many implementations do exactly that.

    It is not the implementation strategy used by `std::list<???>' implementations. All outstanding `std::list<???>' iterators must remain valid after an insertion. In order for a `std::list' to meet those requirements an implementation would have to keep record of free and used nodes in every pool, a reference to every pool, and use jump tables or some other mechanism to keep the iterators valid. It would be too costly on average and all implementations I've seen request new memory for every node inserted from the associated allocator allowing the allocator to manage the pools if they are necessary.

    The standard requires at least amortized constant time insertion into a `std::list'.

    Soma

  8. #23
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Yeah, grumpy kinda confused vector and list there.

    Anyway, writing an allocator that allocates list nodes in blocks of 5 isn't very hard. Writing an allocator that can free those blocks again is tricky, because it basically needs to track which of those blocks are completely freed and which are only partially freed. (But so would any list implementation that employs this strategy.) There are various ways to do that, with different tradeoffs. Generally, though, the overhead of this approach suggests that blocks sizes of 8 or higher are probably better.
    Writing an allocator that makes sure that only one list ever gets nodes from the same block should be easy, but isn't, due to the broken specification of allocators in C++03. In C++0x it's going to be easy. But it can also lead to some nasty hidden inefficiencies in some code, due to swapping no longer being O(1).

    That said, though, one ugly thing about the STL is that the allocator is part of the type. That makes usage annoying, because it means that every function that operates on, say, a list of ints will still have to be a template to accommodate different allocators.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  9. #24
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,256
    That makes usage annoying, because it means that every function that operates on, say, a list of ints will still have to be a template to accommodate different allocators.
    I haven't personally bothered with them, but shouldn't scoped allocators and the adapter alleviate that problem somewhat?

    Soma

  10. #25
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Not this one, no. Scoped allocators and the adapter give you a lot more control over memory allocation in containers, making arguments about needing custom containers for custom memory management even weaker, but they don't change the fact that the allocator is part of most classes using one, in particular all the containers. The classes where this isn't so are function, promise, and packaged_task.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  11. #26
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    Now that is ridiculous. Then every gamer who buys it has to suffer instead.
    So I see you've worked in the game industry, went through making this decision, understood and weighed the arguments for and against custom containers in this case, and decided STL is better.

    Or are you just naively saying STL is the answer to all of life's problems in C++, so doing it any other way is wrong?

    It certainly sounds like it.

    @grumpy: Thanks for the information!

    "not invented here" mentality, or have simply stuck with an in-house approach due to lack of understanding of what the STL actually allows them to do.
    I'm sure they know how to use the STL. They are all very experienced and open minded developers.

    The "not invented here" mentality is in effect here I believe, in a valid way. We are most concerned about differences (both space and time) between different STL implementations, since the engine needs to support many (~5) platforms, and of course they don't all implement STL the same way. They will all have different performance and memory usage characteristics.

    So we roll our own to "level the playground" so to speak. Containers are at the very lowest level of this highly optimized game engine. Do we really want to use so much code we don't know and can't change down there?

    Using the STL brings in a lot of risk.

    With a bunch of hacks we can probably make it perform well on one platform. What if the publisher suddenly comes in and tell us to port it to some new platform? We do it, build, it compiles, runs, and gives us 1fps. We'll profile it, and the culprit turns out to be STL. What do we do then? Re-hack everything for this STL?

    What if a new version of Visual Studio comes out where they changed the STL a bit, and suddenly we see a 50% performance drop?

    Afterall, it's about saving time. With a millions of lines game engine, the time it takes to write a few highly optimized (for our purpose) containers tightly coupled with the rest of the system is negligible. And it can save a lot of trouble down the road, giving us a lot more flexibility and certainty. It can end up saving a lot of time.

    The 5 blocks thing is just a non-sense example I came up with so phantomotap can back up his claim that you can do "all that" with an allocator. He's apparently not interested in doing that, so please forget about it now. Sorry about that.

  12. #27
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,596
    Quote Originally Posted by cyberfish View Post
    So I see you've worked in the game industry, went through making this decision, understood and weighed the arguments for and against custom containers in this case, and decided STL is better.

    Or are you just naively saying STL is the answer to all of life's problems in C++, so doing it any other way is wrong?

    It certainly sounds like it.
    No, it wasn't directed at STL. It was directed at the "if something is slow, upgrade, don't optimize.".
    (The STL is something I'm not about to discuss.)
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  13. #28
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    Quote Originally Posted by Elysia View Post
    No, it wasn't directed at STL. It was directed at the "if something is slow, upgrade, don't optimize.".
    (The STL is something I'm not about to discuss.)
    Ah ok. I apologize.

  14. #29
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by cyberfish View Post
    Using the STL brings in a lot of risk.

    With a bunch of hacks we can probably make it perform well on one platform. What if the publisher suddenly comes in and tell us to port it to some new platform? We do it, build, it compiles, runs, and gives us 1fps. We'll profile it, and the culprit turns out to be STL. What do we do then? Re-hack everything for this STL?
    What if your custom containers give you 1fps on the new platform?

    Quote Originally Posted by cyberfish View Post
    What if a new version of Visual Studio comes out where they changed the STL a bit, and suddenly we see a 50% performance drop?
    Then throw away the new STL and use the old one. They're just a bunch of header files that you can copy around...

    If a company already has their own containers that they've tested and they're using, and they're happy with them, then obviously they should continue using them. If you're starting from scratch though, you should probably at least consider whether or not using the STL or writing your own is better.
    "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

  15. #30
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    What if your custom containers give you 1fps on the new platform?
    Then we're in for some more hacking. There is no way around that.

    But the chance of that is very small. Realistically speaking, you won't get that kind of performance differences compiling the same code using different (modern) compilers.

    Using STL is different. It will be compiling different code (from different implementations of STL).

    Then throw away the new STL and use the old one. They're just a bunch of header files that you can copy around...
    That's not so practical in the long run is it...

    If a company already has their own containers that they've tested and they're using, and they're happy with them, then obviously they should continue using them. If you're starting from scratch though, you should probably at least consider whether or not using the STL or writing your own is better.
    I agree. I'm fairly certain they did evaluate the option of using the STL before deciding to go custom. Though I don't know the specifics of what went into that decision.

Page 2 of 3 FirstFirst 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, 04:52 PM
  2. im extreamly new help
    By rigo305 in forum C++ Programming
    Replies: 27
    Last Post: 04-23-2004, 11:22 PM
  3. STL or no STL
    By codec in forum C++ Programming
    Replies: 7
    Last Post: 04-12-2004, 02:36 PM
  4. Prime Number Generator... Help !?!!
    By Halo in forum C++ Programming
    Replies: 9
    Last Post: 10-20-2003, 07:26 PM
  5. include question
    By Wanted420 in forum C++ Programming
    Replies: 8
    Last Post: 10-17-2003, 03:49 AM

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