From: David B. Held (dheld_at_[hidden])
Date: 2003-02-03 01:28:07
"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. 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.
> It's possible, but you don't yet have a single case of that you can
> point at, whereas you have quite a few cases of EBO failure in the
> MI case. I would be going with an organization that has never failed
> to be "tight" rather than trying to trick the compiler into tightening an
> organization that commonly bloats.
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.
> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk