[boost] Re: SmartPtr - Exception safety reprise

From: David B. Held (dheld_at_[hidden])
Date: 2003-02-01 19:39:21

"David Abrahams" <dave_at_[hidden]> wrote in message
news:ud6mbd2f5.fsf_at_boost-consulting.com...
> [...]
> Up to a point.  I know MWerks is object-compatible in the
> single-inheritance case (for the sake of COM and MFC), but not
> if there's MI.  However, they still have MI EBO problem.
>
> Further, this is not a Win32-specific problem.  Most Unix compilers
> that aren't GCC-3.x have it as well, AFAICT.

So in your opinion, *ought* the optimally_inherit solution to work
even on these compilers?

> [...]
> I guess that's OK if you don't care how many ctors and dtors get
> called.  The lifetimes of these temporaries obviously won't mirror
> that of the smart_ptr.  Sounds like a fragile arrangement to me.

I imagine that the temporaries won't get created at all, since their
sole purpose is to verify policy compatibility.  In the majority of
cases, they will simply call an appropriate copy c'tor, which will be
trivial or generated, because the class has no state.

> > Unfortunately, EBO interacts with non-empty bases as well as
> > empty ones, and that is our problem.
>
> If you only inherit from non-empty bases, how is EBO relevant at
> all?

That's a very good question.  Maybe I should call it an "Empty
Derived Optimization" problem.  For some reason, even in this
configuration, VC++ insists that sizeof(smart_ptr) > 8:

class smart_ptr
    : optimally_inherit<
        optimally_inherit<storage, checking>,
        optimally_inherit<ownership, conversion>
    >
{ ... }

I can prove that optimally_inherit<storage, checking> only derives
from storage, and similarly for ownership with a simple test case.
So why VC++ thinks it needs to inflate the size of smart_ptr is
beyond me.  But it isn't just smart_ptr.  It inflates the size of the top-
level optimally_inherit, which is inheriting from two non-empty base
classes.  Perhaps we should call it the "Non-emtpy Base MI
Pessimization" (NoBMIP)?  I assumed it was because it didn't
want any of the bases to share an address with the derived class,
which is analogous to the EBO case.  But perhaps I misunderstand
what is going on, and you can shed some light on it for me.

> [...]
> > I know that optimally_inherit *does* work under VC++ for some
> > cases.  I just don't know exactly what those cases are, and I don't
> > really want to spend a week trying to discover it, especially as that
> > won't help people who are writing custom policies.
>
> Why not?

Well, suppose that I discover *some* configuration in which EBO and
optimally_inherit produce the desired size, but I don't know *why*
that configuration has the desired result.  How is a user to know if his
custom policy is going to kill EBO again or not, based on the working
configuration?

Dave