Re: [boost] Re: SmartPtr - Exception safety reprise

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
> news:001201c2ce26$533cae40$6501a8c0_at_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