bslstl_stringbuf::str() doesn't respect the allocator

[EricHripko]

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?

[RMGiroux]

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.

[dribeas]

I believe you will find an example in ostringstream. There was some discussion back in the day to add another overload as an extension.

----- Original Message ----- From: Mike Giroux reply@reply.github.com To: bde@noreply.github.com CC: subscribed@noreply.github.com At: 12-Nov-2018 19:13:19

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.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[EricHripko]

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.