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
>> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk