Re: [boost] Traits-based design and ODR

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2002-04-29 20:58:18

[Andrei]
> In my previous posts, I mentioned that I agree that policy-based smart
> pointers are better used in implementation rather than interfaces. In
light
> of all of the above, I am now tempted to say that policy-based smart
> pointers are also the best vehicle for interfacing templated code, and
that
> the alternatives are suboptimal, dangerous, or both. That is, unless I've
> made some terrible mistake, case in which I'd be glad to stand corrected.

If you have made some terrible mistake I have not seen it (not in this post,
at least).
However, I think there is still some merit in Dietmar's assertion that
policy based smart pointers have issues when used in interfaces. I don't
especially agree with his more detailed break-down - and especially not with
his traits proposal (certainly not in view of your observations in this
post). However, he did confess that he didn't really have a proposal for a
solution.
I have been wondering (but not had time to experiment) whether a possible
compromised approach could be to have a smart pointer type for interfaces
where any policies that need not be exposed in the type *after construction*
are held opaquely as runtime policies. While this may not be as efficient as
the compile time versions, they would compliment, rather than replace, their
richer-typed brethren.
Conversion constructors for perhaps a wider range of alternative
compile-time variants may be provided which absorb the richly-configured
objects without losing that configuration, but only exposing the policies
that unavoidably need to be part of the explicit type of the interface
oriented smart pointer (for example, you would certainly want to know if a
smart pointer featured destructive copy!)
I may be using too many ambiguous terms here because I don't have a concrete
example, but I hope you see what I am getting at. I don't expect all types
other than the pointee type to be eliminated for the interface, as Dietmar
aims for, but by reducing them to the minimum set this could mitigate the
situation.

Is this a possibility?

[)o
IhIL..