3 ms·

The STL has huge mistakes like the completely useless "std::list". It also does a whole lot of unnecessary dynamic allocations due to the non-intrusive style u

by Peaker 12y ago

The STL has huge mistakes like the completely useless "std::list". It also does a whole lot of unnecessary dynamic allocations due to the non-intrusive style used for all of its containers. I think the STL might be overhyped.

cageface 12y ago
95% of my use cases are satisfied by std::vector and std::map. Neither one has ever even shown up as a tiny blip in my performance traces, even in debug builds. If you really really need intrusive containers you can get them from boost. Like anything in decades of heavy commercial use it has some warts but at least C++ gives you the control you need to write fast code at a reasonable level of abstraction.
- Peaker 12y ago
  I wasn't dissing C++ here (though I do believe C++ has quite a few downfalls..), just the STL. std::vector is completely reasonable implementation for a dynamic vector. std::map is somewhat unreasonable, because its non-intrusiveness requires dynamic allocations, more indirections, and more expensive deletions. std::list is useless, so when you do want linked lists, you end up using the wrong data structure, because list is out of the lexicon.
srean 12y ago
It would help if you could point me to something that is better than STL (in performance and ease of use) and addresses the full scope of STL. I have asked this a few times, but all I have got so far is cricket chirps or pointers to worse bloatware. Not claiming that such a thing does not exist, rather would be happy to give such a thing a try. It would also lend more heft to your comment.
- mtdewcmu 12y ago
  Any library that addresses exactly the same use case as STL is going to have the same limitations as STL. Everything is a trade-off. I think you can probably assume that STL does about as good a job as any library would, given identical trade-offs. Note that the actual implementations will vary by platform and compiler.
- Peaker 12y ago
  The STL is an arbitrary collection of libraries. For any specific library within it, I might be able to. For example, the Linux kernel's list.h is far superior to std::list.

by Peaker 12y ago

cageface 12y ago

95% of my use cases are satisfied by std::vector and std::map. Neither one has ever even shown up as a tiny blip in my performance traces, even in debug builds. If you really really need intrusive containers you can get them from boost. Like anything in decades of heavy commercial use it has some warts but at least C++ gives you the control you need to write fast code at a reasonable level of abstraction.

Peaker 12y ago
I wasn't dissing C++ here (though I do believe C++ has quite a few downfalls..), just the STL. std::vector is completely reasonable implementation for a dynamic vector. std::map is somewhat unreasonable, because its non-intrusiveness requires dynamic allocations, more indirections, and more expensive deletions. std::list is useless, so when you do want linked lists, you end up using the wrong data structure, because list is out of the lexicon.

srean 12y ago

It would help if you could point me to something that is better than STL (in performance and ease of use) and addresses the full scope of STL. I have asked this a few times, but all I have got so far is cricket chirps or pointers to worse bloatware. Not claiming that such a thing does not exist, rather would be happy to give such a thing a try. It would also lend more heft to your comment.

mtdewcmu 12y ago
Any library that addresses exactly the same use case as STL is going to have the same limitations as STL. Everything is a trade-off. I think you can probably assume that STL does about as good a job as any library would, given identical trade-offs. Note that the actual implementations will vary by platform and compiler.
Peaker 12y ago
The STL is an arbitrary collection of libraries. For any specific library within it, I might be able to. For example, the Linux kernel's list.h is far superior to std::list.