"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > [...] > 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. Dave _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
