"David B. Held" <[EMAIL PROTECTED]> writes:
> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>> [...]
>> 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
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
