[boost] Re: SmartPtr - Exception safety reprise

From: David B. Held (dheld_at_[hidden])
Date: 2003-02-06 17:56:25

"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.

> [...]
> 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.

Dave