[boost] Re: SmartPtr - Exception safety reprise

From: David B. Held (dheld_at_[hidden])
Date: 2003-02-02 22:12:45

"David Abrahams" <dave_at_[hidden]> wrote in message
news:ur8aq4eki.fsf_at_boost-consulting.com...
> > [...]
> > 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,

But the compiler can, right?

> especially taking arbitrary arguments.

If the arguments are all references, there are no data members, and there
is no body, I'd say that's pretty trivial.

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

But the compiler knows this too.  So if the c'tor and d'tor are both
trivial,
why not just optimize them away?

> [...]
> If that's all you care about you could just do
> BOOST_STATIC_ASSERT((is_convertible<U2,T2>::value));

Does this work reliably on all platforms?  If so, that is a better solution.

> [you snipped the context for my question]

Sorry, sometimes I am overzealous in my snipping.

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

Well, the idea is that when you construct a pointer with one checking
policy from a pointer with a different checking policy, you enable
convertibility by writing the appropriate c'tor in your checking policy.

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

Right.  I was just explaining why I was creating temporaries in the first.
place.  You said:

> If you don't care about ctors and dtors, it sounds plausible,

which I took to mean that you thought having extra c'tor/d'tor calls for
optimally_inherit would make things fatter/slower.  I was just trying to
argue that I expected most of it to get optimized away.

> > [...]
> > 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.

Maybe I wasn't clear.  At one point, the MI implementation reported
sizeof(smart_ptr) == 8 on VC++.  Changing around the policy code,
I somehow made VC++ inflate the size to 12.  What I'm saying is that
I don't know if that occurred *just because of MI*, or if the same type
of thing might occur with a chained policy implementation.  That is, it
seems conceivable to me that there might exist some configurations of
the chained policy setup in which the sizeof(smart_ptr) gets inflated for
some inexplicable reason (unless you know for sure this won't happen).
So the fact that the first version of the chained policy gave sizeof == 8
doesn't give me confidence that *every* version of the chained policy
will have the desired property.  For all I know, adding a certain number
of member functions to some policy will cause VC++ to decide that
now it's going to make sizeof(smart_ptr) == 12 or 16 or whatever
number it likes.  It would be nice to have some assurance that this
won't happen, but the current state of affairs with the MI setup doesn't
exactly involve EBO, and so I'm afraid that the chained policy
configuration might be susceptible to the same fate.

Dave