[boost] Re: SmartPtr - Exception safety reprise

From: David B. Held (dheld_at_[hidden])
Date: 2003-02-02 14:47:48

"David Abrahams" <dave_at_[hidden]> wrote in message
news:ud6mbbbcb.fsf_at_boost-consulting.com...
> [...]
> Borland is particularly strange about layout.

Suprisingly enough, BCB 5 has maintained the optimal size throughout
all the changes.

> [...]
> Whaaa?  A temporary that never gets created?

Well, I'll show you the code, and  you tell me if it gets optimized away
or not:

    // Inherit first
    template <class T1, class T2>
    class optimal_parents1 : public T1
    {
        // ...

        template <class U1, class U2>
        optimal_parents1(optimal_parents1<U1, U2> const& rhs)
        : T1(static_cast<U1 const&>(rhs))
        { U2 u2; T2 t2(u2); }         // Here

        // ...
};

If T2(U2 const&) is empty, I would think that it wouldn't bother to
call it in the first place.  Am I missing something?  Maybe I shouldn't
have called t2 a temporary, since it is an lvalue.  I just meant that
it's not really used for anything other than making sure that U2 can
be converted to T2.

> [...]
> Maybe you should illustrate what you mean, 'cause I'm lost.

assert_check(no_check const&)
{ }

This allows you to create a pointer with stricter checking from a
pointer with no checking.  But no_check has no such conversion
c'tors, because presumably, one does not want to *reduce* the
level of checking.  Since the checking policies generally don't have
any state, the c'tors are all trivial, and hopefully, will get optimized
out of existence.  They merely serve as a compile-time check of
compatibility.

> [...]
> I don't think I can do any better than you.  I have the same tools at
> my disposal.  I'd do a bunch of experiments and look at the
> resulting class layouts by checking the size and the relative addresses
> of members.

I was afraid it was going to come down to that.

> [...]
> You could probably figure out the VC++ algorithm by
> experimentation, but that still wouldn't help a user trying to write
> portable, efficient code, unless you find a workaround for every
> other compiler.

Yeah, that's the problem. :(  Even more disturbingly, it's not clear if
this is just an MI problem, or a problem with inheritance in general
with VC++.  I mean, when I tried the chained policy implementation,
it did provide the right size, but that doesn't mean it won't change if
I update the implementation (and that version would require a lot of
changes to get it up to speed with the MI version).

Dave