Re: [boost] Re: SmartPtr - Exception safety reprise

From: David Abrahams (dave_at_[hidden])
Date: 2003-02-03 03:17:01

"David B. Held" <dheld_at_[hidden]> writes:

> "David Abrahams" <dave_at_[hidden]> wrote in message
> news:uk7gi2c0i.fsf_at_boost-consulting.com...
>> [...]
>> The problem arises if the user passes an empty policy class with
>> non-trivial ctor or dtor: then the fact that it's being
>> constructed/destructed at different times from the rest of the bases
>> will have visible effects.
>
> Ok, now I see the problem, and one conceivable scenario for this is
> an intrusive ownership policy.  It would most likely be empty, yet the
> cleanup would occur in the d'tor under my latest model, so that it has
> proper exception safety.  Ouch.  On the other hand, I just saw a
> reference to Josuttis & Vandevoorde that I recalled reading whereby
> they refer to a BaseAndMember idiom in which they aggregate the
> non-empty parameter and derive from the emtpy one, relying on
> EBO to give optimal size.  

That's called boost::compressed_pair.

> Once again, I might be able to reverse the logic and aggregate the
> empty member and derive from the non- empty one.  I guess that
> depends on how well VC++ & friends perform empty member
> optimization.

There is no such thing as empty member optimization.

> That's true, but we're no longer talking about EBO failure.  Even after
> the empty bases have been eliminated, we still get bloating.  So it's
> just random size adjustment.  But you're right that some testing might
> increase the confidence that the size won't go up.

I bet you it's not random, but associated with MI.

>> [...]
>> > It would be nice to have some assurance that this won't happen,
>> > but the current state of affairs with the MI setup doesn't exactly
>> > involve EBO
>>
>> I don't know what you mean by that.
>
> I mean, the optimally_inherit eliminates the empty bases, and yet
> there is size bloat.  So VC++ makes the class bigger for some other
> reason than that it has empty bases.  I will try to write some tests to
> see why that is, or at least how.

I repeat, I bet it's MI-related.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution