[cfe-dev] __vector_base::__destruct_at_end

[Howard Hinnant]

On Jun 26, 2013, at 12:21 PM, Howard Hinnant <hhinnant at apple.com> wrote:

> On Jun 26, 2013, at 11:15 AM, Shriramana Sharma <samjnaa at gmail.com> wrote:
> 
>> Hi and thank you very much for your reply.
>> 
>> On Wed, Jun 26, 2013 at 8:29 PM, Howard Hinnant <hhinnant at apple.com> wrote:
>>>> void __destruct_at_end(const_pointer __new_last, true_type) _NOEXCEPT;
>>>> __destruct_at_end(const_pointer __new_last, false_type)
>>> 
>>> This is an optimization that I found was not working, so I disabled it with the intent of pulling it out completely if the disabilization went well.  It has, I'll pull it out.
>> 
>> So which of the two will remain? Do I presume the false_type version?
>> (And I presume the true_type/false_type thing is an idiom to avoid
>> creating a differently named delegate function? But a differently
>> named delegate may clarify the purpose of the segregation, no?)
> 
> The false_type version will remain, folded into the __destruct_at_end(pointer __new_last).  This technique is used to chose among multiple implementations at compile time, without instantiating the unchosen branches.
> 
>> 
>>>> Also: why separate all the containers into __container and
>>>> __container_base with the former inheriting from the latter? Can't it
>>>> be done in a single class?
>>> 
>>> This is a C++03 technique for making container constructors exception safe.  Let's look at an example:
>> 
>> Wow very nice explanation, thank you very much! I much prefer the
>> try-catch model. Why isn't it then preferred in the libc++
>> implemented? IMO less convoluted, and would avoid lots of base::method
>> calls, no?
> 
> In the base class design the clean up code goes in one place:  ~base().  In the try-catch design the clean up code gets repeated in each constructor.  One could shuffle the clean up code off to a single function, but one still has to replicate the try/catch(...) {clean_up();} for each constructor.

Oh, almost forgot.  For the case that client code terminates with an uncaught exception, the base class design leaves a better stack trace on most OS's.  If there are no try/catch(...) {throw;} in the unwinding, the stack trace starts from where the exception is thrown, otherwise it starts at the re-throw;.

Howard