Re: out_ptr's formal review starts now!

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2019-06-26 08:26:00

On 6/26/19 3:25 AM, Gavin Lambert via Boost wrote:
> 
> One such example of this is that (especially for header-only libraries, 
> although with care this can also be used for compiled libraries) it is 
> very useful to be able to allow multiple versions of a library to 
> co-exist through external namespacing:
> 
> namespace v1
> {
> #include <library_v1/lib.hpp>
> }
> namespace v2
> {
> #include <library_v2/lib.hpp>
> }
> 
> Most of the time this Just Worksâ„¢;

I'd say, most of the time it doesn't work. Including any foreign 
headers, including standard library headers, in lib.hpp will break the 
program at some stage, either compilation or linking.

I'm not saying I like specialization as a way of customization though.

> On 26/06/2019 10:05, Andrey Semashev wrote:
>> Not calling reset() on outer exception makes sense if you require
>> that the function that threw it either didn't allocate or freed the
>> memory before the exception propagated out of the function. In other
>> words, if the function fails, it must clean up the mess after itself
>> before returning, exception or not. This is not an unreasonable
>> requirement, and in fact, this is the only behavior I consider
>> reasonable in the context of raw pointers.
> That's fine -- if it was the function itself which throws the exception. 
>  Â (And that shouldn't normally be the case because it's a C-style API.)
> 
> But what if the function has two output parameters?  Memory is allocated 
> for both and returned as a raw pointer by the function.  One of the 
> out_ptrs is then destroyed and calls reset(), and this throws.  The 
> other out_ptr is then destroyed as well, and now it has a problem; it 
> either has to call reset() as well and possibly throw yet again, or leak 
> memory.

Good point. In that case I see no good solution, given that on error 
there may be garbage in the out pointers.