Hacker News Reader

Comment by jeffbee | Hacker News Reader

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.

View on HN

folly provides functions to resize std::string & std::vector without initialization [0].

[0] https://github.com/facebook/folly/blob/3c8829785e3ce86cb821c...

Yeah, it's nice! And Abseil does it, IFF you use LLVM libc++.

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.

> Google also proposed uninitialized resize

What would be the practical difference to std::string::reserve?

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.

Also I don't think the Standard requires that data() returns a valid pointer after only calling reserve(), so it's technically UB.

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

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.

Reply on news.ycombinator.com