3 ms·

> Ditto for the other data structures in the library. I agree with your observations, but I don't know if I agree with this part. For example, if you've alrea

> Ditto for the other data structures in the library. I agree with your observations, but I don't know if I agree with this part. For example, if you've already chosen to make a dynamic-resizing heap buffer, you're probably going to write something no better than std::vector. I know this because I've written the same thing many times working in .c files. It's handy to have that one standardized. Of course, the lack of a good one of those will make the dynamic-resizing heap buffer a less common choice in C, so in that sense maybe you're right.

petschge 7y ago
While your probably will not write something better than std::vector in a good c++ library such as libc++, it is quite possible to do better than a bad implementation of std::vector. Source: I have done better than the std::vector that was shipped with the compiler on an old sun.
- asveikau 7y ago
  I have an old sun with their old compiler powered off in my home, I could check it out. What is the complaint though? Bad realloc strategy? Come to think of it, the worst part of how vectors historically have been was not vector itself, but the requirement to use the copy constructor at reallocation time. C++11 and move semantics fixed that.
  - petschge 7y ago
    That was a decade ago and I don't remember. My main point was: Yes it is good to have a standard implementation that comes shipped with C++, but that does not mean you can not do better for your special case. And it might be possible with surprisingly little code.
    - gpderetta 7y ago
      It took a lot of time for most C++ compilers to get good at removing abstraction. It was so bad that Stepanov wrote the abstraction penality benchmark to name and shame compilers. In particular vectors with class type iterators (as opposed to using raw pointers) paid an heavy penality. Is it possible that your vector used raw pointers as iterators?
userbinator 7y ago
For example, if you've already chosen to make a dynamic-resizing heap buffer, you're probably going to write something no better than std::vector. Of course, the lack of a good one of those will make the dynamic-resizing heap buffer a less common choice in C, so in that sense maybe you're right. Precisely. If you need a dynamically resizeable buffer then using std::vector will be a very good idea, but perhaps you don't really need it; the lack of such "ready-to-use" data structures in C encourages more thought on whether it's necessary to do so, and as a result you might end up with a more efficient solution which doesn't. Another example is using a std::map<char, something> - no compiler I know of will replace that with a 256-element array, despite the latter being much more efficient than the former when you use most of the values.

petschge 7y ago

While your probably will not write something better than std::vector in a good c++ library such as libc++, it is quite possible to do better than a bad implementation of std::vector. Source: I have done better than the std::vector that was shipped with the compiler on an old sun.

asveikau 7y ago
I have an old sun with their old compiler powered off in my home, I could check it out. What is the complaint though? Bad realloc strategy? Come to think of it, the worst part of how vectors historically have been was not vector itself, but the requirement to use the copy constructor at reallocation time. C++11 and move semantics fixed that.
- petschge 7y ago
  That was a decade ago and I don't remember. My main point was: Yes it is good to have a standard implementation that comes shipped with C++, but that does not mean you can not do better for your special case. And it might be possible with surprisingly little code.
  - gpderetta 7y ago
    It took a lot of time for most C++ compilers to get good at removing abstraction. It was so bad that Stepanov wrote the abstraction penality benchmark to name and shame compilers. In particular vectors with class type iterators (as opposed to using raw pointers) paid an heavy penality. Is it possible that your vector used raw pointers as iterators?

userbinator 7y ago

For example, if you've already chosen to make a dynamic-resizing heap buffer, you're probably going to write something no better than std::vector. Of course, the lack of a good one of those will make the dynamic-resizing heap buffer a less common choice in C, so in that sense maybe you're right. Precisely. If you need a dynamically resizeable buffer then using std::vector will be a very good idea, but perhaps you don't really need it; the lack of such "ready-to-use" data structures in C encourages more thought on whether it's necessary to do so, and as a result you might end up with a more efficient solution which doesn't. Another example is using a std::map<char, something> - no compiler I know of will replace that with a 256-element array, despite the latter being much more efficient than the former when you use most of the values.