[boost] Re: Boostifying Loki::SmartPtr

From: David B. Held (dheld_at_[hidden])
Date: 2002-04-20 14:31:56

"Gennadiy Rozental" <rogeeff_at_[hidden]> wrote in message
news:a9raf4$sl8$1_at_main.gmane.org...
> [...]
> Frankly speaking I do not feel that we resolved most of the issues to put
> something under cvs

You don't think it would be a good idea to put something under, say, the
development branch, so people can see what's being discussed, and/or
offer alternatives?  So far, I've made the code work (under an extremely
small test case) on gcc 3.0 and bcc 5.5.  It's missing alternatives for
compilers
with BOOST_NO_MEMBER_TEMPLATES, but that is simply because
I've addressed other issues first.  I incorporated the following changes you
suggested, that Andrei agreed to:

2b. Rename OP, CP, KP, etc.

3. const versions of pointer_type and reference_type

10a. Moved destructor (wasn't sure if release_reference is necessary,
but will make the change if it is decided that it's compellingly better)

13. Not sure where get() was supposed to go.  This seems related to
the disagreement over whether get() should be free or member.

14. Changed operator*() and operator->() to get_reference() and
get_pointer()
in StoragePolicy.

15. Changed operator*() const, etc. to return appropriate const_ types.

17. Didn't get to it yet.

19. Not sure what "Igen" means...Andrei?

So far, the primary principle I have applied is to leave as much of Loki
intact as possible.  The second principle is to make sure there is agreement
before making changes.  The changes mentioned above, everybody can
agree on.

The other changes you suggested look like they could use some more
discussion.  As far as refactoring to a linear inheritance hierarchy
("method 1")
or Andrei's "method 2", it seems like the vote is 2-1 in favor of "method
1",
since my vote isn't really an informed technical vote.  Still, it doesn't
seem
like there is absolute agreement that "method 1" is clearly and
unambiguously
the best way.  In particular, it seems to not be clear which compilers do
EBO for MI, and which do not; nor whether we can expect or not expect
compilers to do so in the near future.

In using boost::ct_if, I had to use the alternative ct_if_t to make it work
with
bcc.  I could have used ct_if_t exclusively (like I suppose Jeremy probably
did with BGL), and left out the conditional compilations.  However, the
ct_if version is more elegant and is legal C++.  So I created a
BOOST_BCC_NON_TYPE_TEMPLATE_PARAMETERS macro to
indicate that we are working around a bug in bcc's non-type template
handling.  This may seem annoying, but by using both the "pure" ct_if
version
and the "hacked" ct_if_t version, we are reminding Borland that everyone
else got this right, and their bug is making otherwise nice-looking code
look
bad.  Hopefully, that will inspire them to fix it in future versions.

Although I realize there are theoretical advantages to a linear inheritance
hierarchy, as Dave A. mentioned, it seems the primary argument for
abandoning MI in this case is a pragmatic, compiler-specific one.  To that
end, I would like to incorporate as many of the other changes to the current
MI version as possible, first.  Once we have something that a lot of people
like, I am willing to try to apply the linear hierarchy change and maintain
both versions in parallel, so we can run tests on a lot of compilers, and
see just how bad the problem is (unless we are convinced that it is a
bad problem on a majority of compilers).  From some of the other posts
I've seen, it looks like the EBO results are mixed, and we might just
get lucky with smart_ptr (or we might have to engineer in some luck ;).

Is that all reasonable?

Dave