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
} namespace v2 { #include } 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.