"David B. Held" <[EMAIL PROTECTED]> writes:
> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>> [...]
>> 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?
Sigh. We can't detect the presence of trivial constructors,
especially taking arbitrary arguments. What is_empty<> does is detect
classes which the EBO can potentially optimize away, i.e. those with
no data members. T2 may have a non-trivial destructor to boot.
> 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.
If that's all you care about you could just do
BOOST_STATIC_ASSERT((is_convertible<U2,T2>::value));
[you snipped the context for my question]
>> 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.
>> [...]
>> 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.
You're not showing much. I'll take your word for it.
> 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've been concerned about optimizing storage, not code. The EBO issue
has nothing to do with inlining constructors.
>> [...]
>> 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).
I've been saying this over and over: yes it does, for all practical
purposes. Vendors are VERY reluctant to break object code
compatibility. If they ever do break it intentionally, it will only
be to do *more* optimizations, not fewer.
--
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
