Re: [boost] Re: Boostifying Loki::SmartPtr

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2002-04-28 07:32:15

[David B. Held]
> 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.

[snip]

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

Hi Dave (and co), sorry to come to this late - hope you're still reading the
thread :-)

Could the decision as to whether we use a linear inheritance hierarchy or MI
be deferred to yet another policy? (YAP?). By inheriting smart_ptr
immediately from, say, policy_mixer (for want of a better thought out name),
we leave it to policy mixer how to, well, mix the policies.
It seems to me that compiler limitations (and legal ones in this case) are a
primary concern here, but not necessarily the only ones.
Of course, some thought would need to be given as to how to _use_ the
policies in a way detached from the way they are composed... just thinking
out loud I suppose....

Regards,

[)o
IhIL..