bslstl_stringbuf::str() doesn't respect the allocator
EricHripko opened this issue · 3 comments
Overview
bslstl_stringbuf
is marked as allocator-aware and is by default constructed with bsl::allocator
. However, it doesn't seem like the allocator is respected in some operations (namely, str()
). It seems to me that this is a bug.
Expected behaviour
The allocator is propagated to the str()
method and the returned string is allocated with the specified allocator.
Actual behaviour
The allocator is not propagated to the str()
method and the returned string is allocated with the bslma::Default::defaultAllocator()
.
Would you be willing to accept a tiny patch that fixes this behaviour?
I believe this is actually working as designed - I'm pretty certain don't use internal allocators to instantiate objects returned by value. The code has to work as expected on C++03 implementations that might not elide the copy on return.
We also don't tend to return objects by value, so it's hard for me to find another example to point to - we usually let the caller create the object with the desired allocator then pass it in by pointer so we can write in to the existing correctly-allocated object.
In this case, we have to return by value to satisfy the standard.
Yes, ostringstream
is how I found out about it. Seems quite counter-intuitive.
Thank you for the detailed explanation. Closing this, as there's nothing to be done.