From: "David B. Held" <[EMAIL PROTECTED]> > "Dave Abrahams" <[EMAIL PROTECTED]> wrote in message > 001201c2ce26$533cae40$6501a8c0@penguin">news:001201c2ce26$533cae40$6501a8c0@penguin... > > [...] > > It's clear to me why that could happen. It could be just a simple- > > minded rule to avoid violating the standard requirements, which > > are written so that no two objects of the same type can have the > > same address. The rule would be, "if I applied the EBO on this > > type, add some padding after it in an MI context so that other > > bases of the same type can't end up overlapping with it. It's a > > dumb rule, since it's easy enough to lay out empty bases in the > > single-inheritance case at the beginning of the object, and since > > all types have size > 0, you don't need to do anything other than > > "not optimize" in the MI case. > > So it's actually a pessimization as the result of an optimization? > Ouch.
That's one plausible explanation. > > [...] > > I'm interested in what happens when either of ownership or > > storage are themselves empty. > > Oddly enough, VC++ gets the size right for destructive_copy (4), > but bcc insists the size is 8. In this case, I don't know what's going > on, because optimally_inherit only leaves one base class (which > can be proven by trying to static_cast to the policies), so there > isn't even MI involved. It's just outright EBO failure. > > > And, of course, the independent tests not based on smart_ptr. > > I've done some of these. When I first ran across size problems, > it was the first thing I did. However, the simplicity of the tests does > not give you a good idea of what happens in smart_ptr. That is, a > lot of the simple tests pass with the desired results. It's when > the tests get more and more smart_ptr baggage that you begin > to see different results. It will be a lot more instructive if you can narrow down which specific piece of baggage is causing the problem so that you're not thinking of this in terms of smart_ptr components all the time. Otherwise, you'll never have a good idea of which policy design choices will cause what size-effects. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
