[boost] Re: Inheritance alternatives for policy-based smart_ptr

From: David B. Held (dheld_at_[hidden])
Date: 2002-04-29 17:01:40

"Gennadiy Rozental" <rogeeff_at_[hidden]> wrote in message
news:aairtf$gko$1_at_main.gmane.org...
> [...] FWIW we have at least 6 design alternatives [...]

I like this summary.

> 1. Loki::SmartPtr style. smart_ptr is inherited from polices it
> parameterized with.
> [...]
> Cons.
>    a. Possible memory overhead caused by MI preventing some
> compilers to perform efficient EBO.
> [...]

This might not be as bad a problem as first suspected.  I just
checked, and gcc 3.0 has sizeof(smart_ptr) == 8 with
boost::loki::smart_ptr on IA-32 with ref_counted, and == 4 with
auto_ptr semantics.  That's right on.  However, bcc has
sizeof(smart_ptr) == 24!!!  Clearly, this is unacceptable.
Fortunately, this is only on QuadWord alignment.  By dropping
down to byte alignment, and pulling some other tricks, I can get
it down to 8 bytes for ref_counted, and 5 bytes for auto semantics.
Unfortunately, I can't get it down to 4 bytes for the auto_ptr style,
because one of the tricks involves putting a dummy variable in
a policy.  A char[0] doesn't do the trick, either. :(

However, in my testing, I found that bcc's MI-EBO is sensitive
to A) the number of empty base classes, B) the order of
inheritance, and C) the size of dummy data members.  In some
cases, a char[0] was apparently enough to provoke MI-EBO,
and in others, it did nothing.  In some cases a plain char triggered
MI-EBO, and in others, no effect.  Things that don't seem to have
an effect, which I tried anyway were: A) access specifiers (I tried
changing policies between structs and classes and varying the
access of function and data members), B) static/member functions,
C) static dummy data.  I couldn't think of anything else that might
remotely have an effect, but I'm open to suggestions.

It may very well be that in the end, chained policies are
philosophically superior.  But I don't think that MI is necessarily
as big a memory hog as once thought.  I might add that bcc is
known as one of the worst optimizers both in terms of speed and
space.  It may turn out that a policy mixer is an acceptable
alternative to policy chaining.

Dave

P.S.  I've uploaded the latest version of boost::loki::smart_ptr
(to distinguish it from the many alternatives that are floating
around ;) along with a small test program.  Hopefully it compiles
on other platforms.  If not, some feedback is appreciated.

The file is now in
http://groups.yahoo.com/group/boost/files/smart_pointers/smart_ptr.hpp
I hope that Beman doesn't mind me cluttering up his folder a
little.  I assume he intended the various smart_ptr suggestions
to end up there, so people would only have to look in one place.

The latest changes that Gennadiy suggested are:

1. Put smart_ptr first, and policies later.

2a. There doesn't appear to be any config macros for say,
BOOST_NO_TEMPLATE_TEMPLATE_PARAMETERS.
Does this mean that Boost in general does not seek to support
compilers that lack template template support?  If so, then
it doesn't seem worthwhile to me to drop the template template
parameters, unless there are more compelling reasons.

5. Andrei waffled on this one, so I'm not sure whether a change
is warranted or not.

8. No clarification here.  Not sure what the suggestion was.

9. Still haven't gotten to it.

10b.  Didn't change release() to release_reference() because
A) Loki called it release(), B) boost::counted_base() calls it
release(), and C) std::auto_ptr calls it release()!

11. It looks like the jury is still out on member vs. non-member
get()/release().  I'll leave it alone until a bigger consensus builds.

12. Andrei says there is a bug in his implementation of release()
where he did not reinitialize the Ownership policy.  If I knew how
this should be fixed, I'd do it.  Andrei, could you clarify?

13. This is related to member vs. non/member get(), but points
out the lack of inter-policy communication in the MI approach.

16. Changed operator! to call storage_policy::is_valid().  This
seemed the most appropriate name to me.

17/20. Changed conversion policy to pseudo-traits
implementation, but somehow broke bcc support for conversion
entirely.

18. Seems like a judgement call.

19. Andrei, could you tell me what "Igen" means?  dictionary.com
was of no help.

21. Gennadiy's Checking policies look big and complicated.
They scared me. ;)  Also, I would like to see more commentary
before switching to them.

22. Same as 21.

I notice that Beman has produced a policy-chaining implementation,
and I will probably take a close look at it to create a full boost::loki
version of it.  Thanks, Beman!