Re: [boost] A solution to return dynamic strings without heap allocation. Any interest?
On 8/29/19 3:24 PM, Roberto Hinz via Boost wrote:
auto result = csw.finish(); if (result.truncated) { // ...
I suggest that you change the return type of finish() to contain the number of element written instead of the truncated boolean. This would make outbuf extensible to binary data as well where you cannot rely on a terminating zero to tell you how much data has been written. The return type could also have begin()/end() member functions, which makes it directly usable with STL algorithms. In that case it would also make sense to have data()/size().
On Sun, Sep 1, 2019 at 7:45 AM Bjorn Reese via Boost
On 8/29/19 3:24 PM, Roberto Hinz via Boost wrote:
auto result = csw.finish(); if (result.truncated) { // ...
I suggest that you change the return type of finish() to contain the number of element written instead of the truncated boolean. This would make outbuf extensible to binary data as well where you cannot rely on a terminating zero to tell you how much data has been written.
The return type could also have begin()/end() member functions, which makes it directly usable with STL algorithms. In that case it would also make sense to have data()/size().
outbuf can be used to binary data, but the basic_cstr_writer class in particular may not be suitable for that, since its finish() function aways writes a terminating zero, requiring an extra space in the destination string. Perhaps we could add another class template, `basic_bin_writer`, that would never write a terminating character. Anyway, the returned result contains a `ptr` member that points to the end of the string. In order to add begin()/data()/size() functions basic_cstr_writer would also need to store the initial position, which would increase its size a little bit. And that's the only reason why I did not add it, since I think it would not be used most of time, and the caller already knows the begin anyway. It's convenience vs tiny cost decision. I will go for the what the majority prefers.
On 9/1/19 3:10 PM, Roberto Hinz via Boost wrote:
outbuf can be used to binary data, but the basic_cstr_writer class in particular may not be suitable for that, since its finish() function aways writes a terminating zero, requiring an extra space in the destination string. Perhaps we could add another class template, `basic_bin_writer`, that would never write a terminating character.
I was thinking more broadly than basic_cstr_write which I happened to quote. I may want my template classes to operate on the return type of any writer in a consistent manner. This is possible if they adhere to ContiguousRange and SizedRange as suggested.
Anyway, the returned result contains a `ptr` member that points to the end of the string. In order to add begin()/data()/size() functions basic_cstr_writer would also need to store the initial position, which would increase its size a little bit. And that's the only reason
Assuming the buffer is contiguous, begin == end - size, so there would be no need to store an extra pointer.
On Sun, Sep 1, 2019 at 11:59 AM Bjorn Reese via Boost
On 9/1/19 3:10 PM, Roberto Hinz via Boost wrote:
outbuf can be used to binary data, but the basic_cstr_writer class in particular may not be suitable for that, since its finish() function aways writes a terminating zero, requiring an extra space in the destination string. Perhaps we could add another class template, `basic_bin_writer`, that would never write a terminating character.
I was thinking more broadly than basic_cstr_write which I happened to quote. I may want my template classes to operate on the return type of any writer in a consistent manner. This is possible if they adhere to ContiguousRange and SizedRange as suggested.
It might be quite a challenge to keep such consistency among writers. Some of them write to file. There is one of them that doesn't actually write anything, but just ignores all content ( the `discarded_outbuf` which is documented I but forgot to implement ). What should finish() return in those cases? And, of course, there are the user-defined writers. We want the library to work in all sort of destination types.
Anyway, the returned result contains a `ptr` member that points to the end of the string. In order to add begin()/data()/size() functions basic_cstr_writer would also need to store the initial position, which would increase its size a little bit. And that's the only reason
Assuming the buffer is contiguous, begin == end - size, so there would be no need to store an extra pointer.
But then we need to store the size. See basic_cstr_writer implementation: https://github.com/robhz786/outbuf/blob/59a6c8c3159eee94c0fcefed3dd52591dba2...
participants (2)
-
Bjorn Reese -
Roberto Hinz