4 ms·

Google has proposed adding precise growth to std::string on with the benefit that it saves quite a bit of memory and time you the string isn't being repeatedly

Google has proposed adding precise growth to std::string on with the benefit that it saves quite a bit of memory and time you the string isn't being repeatedly appended. However, the project rejected the idea. https://reviews.llvm.org/D102727 https://reviews.llvm.org/D102727

jeffbee 3y ago
Google also proposed uninitialized resize, and the ability to treat string as if it were unique_ptr, by just giving it some already-allocated buffer. You can tell they use these internally because the fingerprints of these features are all over the protocol buffers open source libraries. I believe none of them have been adopted by the standard.
- terrelln 3y ago
  folly provides functions to resize std::string & std::vector without initialization [0]. [0] https://github.com/facebook/folly/blob/3c8829785e3ce86cb821cc87853cfd2b823c6a13/folly/memory/UninitializedMemoryHacks.h#L49-L51 https://github.com/facebook/folly/blob/3c8829785e3ce86cb821c...
  - jeffbee 3y ago
    Yeah, it's nice! And Abseil does it, IFF you use LLVM libc++. https://github.com/abseil/abseil-cpp/blob/master/absl/strings/internal/resize_uninitialized.h https://github.com/abseil/abseil-cpp/blob/master/absl/string... The standard adopted it as resize_and_overwrite. Which I think is a little clunky.
- spacechild1 3y ago
  > Google also proposed uninitialized resize What would be the practical difference to std::string::reserve?
  - jeffbee 3y ago
    Reserve sets the capacity, not the size. If you were to reserve and overwrite the buffer, the size is still wrong. Now if you resize, STL overwrites your contents with value initialized chars.
    - spacechild1 3y ago
      Of course, you need to call push_back() or insert() to add the data. Actually, insert() wouldn't even require reserve() in the first place. I guess the idea of uninitialized resize is that you reserve the space, bump the size, and then you can directly set the new members with operator[]. If your input data is not contiguous, and would need to use push_back() otherwise, you can save a few if-checks. But that's pretty much it, I assume.
    - gary_0 3y ago
      Also I don't think the Standard requires that data() returns a valid pointer after only calling reserve(), so it's technically UB.
      - zabzonk 3y ago
        i think you may have misunderstood the standard - data() will always return a valid pointer, but the pointer returned may be invalidated by any number of functions: string s; s.reserve(50); char * p = s.data(); // ok so far s.reserve(100); // now p may be invalid
  - deleted 3y ago
    [deleted]
rerdavies 3y ago
Fwiw, they seem to imply (admit) that you can get precise growth using s.reserve(n); // precise allocation. s.resize(n); // doesn't grow. or s.reserve(n); s.append(....); // a fairly robust set of overloads. That being said... I completely agree that imprecise resize() is unfortunate, and unexpected. I'm going to have to keep an eye out for how I use resize() going forward. (Not a lot, admittedly).

jeffbee 3y ago

Google also proposed uninitialized resize, and the ability to treat string as if it were unique_ptr, by just giving it some already-allocated buffer. You can tell they use these internally because the fingerprints of these features are all over the protocol buffers open source libraries. I believe none of them have been adopted by the standard.

terrelln 3y ago
folly provides functions to resize std::string & std::vector without initialization [0]. [0] https://github.com/facebook/folly/blob/3c8829785e3ce86cb821cc87853cfd2b823c6a13/folly/memory/UninitializedMemoryHacks.h#L49-L51 https://github.com/facebook/folly/blob/3c8829785e3ce86cb821c...
- jeffbee 3y ago
  Yeah, it's nice! And Abseil does it, IFF you use LLVM libc++. https://github.com/abseil/abseil-cpp/blob/master/absl/strings/internal/resize_uninitialized.h https://github.com/abseil/abseil-cpp/blob/master/absl/string... The standard adopted it as resize_and_overwrite. Which I think is a little clunky.
spacechild1 3y ago
> Google also proposed uninitialized resize What would be the practical difference to std::string::reserve?
- jeffbee 3y ago
  Reserve sets the capacity, not the size. If you were to reserve and overwrite the buffer, the size is still wrong. Now if you resize, STL overwrites your contents with value initialized chars.
  - spacechild1 3y ago
    Of course, you need to call push_back() or insert() to add the data. Actually, insert() wouldn't even require reserve() in the first place. I guess the idea of uninitialized resize is that you reserve the space, bump the size, and then you can directly set the new members with operator[]. If your input data is not contiguous, and would need to use push_back() otherwise, you can save a few if-checks. But that's pretty much it, I assume.
  - gary_0 3y ago
    Also I don't think the Standard requires that data() returns a valid pointer after only calling reserve(), so it's technically UB.
    - zabzonk 3y ago
      i think you may have misunderstood the standard - data() will always return a valid pointer, but the pointer returned may be invalidated by any number of functions: string s; s.reserve(50); char * p = s.data(); // ok so far s.reserve(100); // now p may be invalid
- deleted 3y ago
  [deleted]

rerdavies 3y ago

Fwiw, they seem to imply (admit) that you can get precise growth using s.reserve(n); // precise allocation. s.resize(n); // doesn't grow. or s.reserve(n); s.append(....); // a fairly robust set of overloads. That being said... I completely agree that imprecise resize() is unfortunate, and unexpected. I'm going to have to keep an eye out for how I use resize() going forward. (Not a lot, admittedly).