From: Dave Abrahams (dave_at_[hidden])
Date: 2003-02-06 19:15:10
From: "David B. Held" <dheld_at_[hidden]>
> "Dave Abrahams" <dave_at_[hidden]> wrote in message
> > [...]
> > 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?
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk