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

From: David Abrahams (dave_at_[hidden])
Date: 2003-02-01 18:08:46

"David B. Held" <dheld_at_[hidden]> writes:

> "David Abrahams" <dave_at_[hidden]> wrote in message
> news:ufzr7fyda.fsf_at_boost-consulting.com...
>> [...]
>> What question are you asking?  I think all NDAs on the vc7.1 betas
>> are expired, so I can just run a test...
>
> Actually, I wanted someone on the compiler team to give me a set of
> circumstances under which EBO is guaranteed to work.  If there is no
> way to get MI to fit into those circumstances, then we can give up.
>
>> [...]
>> BTW, VC++ is not the only kid on the block, and the same
>> argument applies to all the other players.
>
> Yes, but you seem to imply that other Win32 compilers try to be
> object-compatible with VC++

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 it seems they should exhibit the same behaviour.
> 
> If there is some way to get the desired optimization,
> with any luck, the other compilers will perform it as well.  Or maybe
> this is wishful thinking?

It is in the case of MWerks, anyway.

>> [...]
>> What is optimally_inherit?  Latest round of changes in what?
>
> Optimally_inherit is a device that is the "dual" of compressed_pair<>.
> Andrei suggested it when this issue first came up.  Whilst
> compressed_pair<> aggregates when a type is non-empty, and
> inherits when it's empty, optimally_inherit inherits when the type
> is non-empty, and just calls c'tors on temporaries when the type is
> empty. This way, empty bases don't actually enter the inheritance
> tree.  

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.

> 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?

> The "latest round of changes" is the set of changes that moves
> cleanup from named procedures (destroy(), release(), etc.) to d'tors.
> For this reason, I suspected that non-trivial user-defined d'tors were
> causing VC++ to drop EBO.  But commenting out the d'tors just to
> check the size did not restore EBO.  So now I would like a VC++
> compiler team member (preferably the one(s) who wrote the EBO
> code) to tell me when EBO works, and when it doesn't, or as much
> about that as possible.  The optimally_inherit trick works just fine
> on BCB, and gcc didn't need it to begin with (that big stud of a
> compiler!).  If we can get VC++ and VC++ wannabes to invoke
> EBO again, we can at least cover a good amount of the market, no?

Yes.

> 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?

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution