Re: [boost] Preliminary release of clone_ptr library

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2006-07-10 01:16:40

On 7/9/06, Kevin Spinar <spinarkm_at_[hidden]> wrote:
>
> First, let me make an assumption.  Most people who would use
> clone_ptr<T> would have T be an abstract base class with no member
> variables.  Now, how would someone write a sorting predicate with
> that?  Double dispatch is a solution, but probably not a desirable
> solution.  Or is my assumption incorrect?

Right, for most uses it would be difficult to implement. Still, as tough as
it is, comparing the pointer value simply isn't correct, so I wouldn't even
consider that an option at all. If you agree, then the only options I can
think of are either some form of forwarded operation, or no definition at
all. It's true that neither one seems great, so maybe there is a better
solution out there, but I personally don't see it. The only reason I am
leaning towards some form of forwarded solution is that in the case that
comparison operators actually are implemented, it allows the user to work
with sorted containers and algorithms without having the explicitly specify
a comparison predicate. To be honest, I don't mind either way as I
personally don't have much of a need for the comparison functionality.

That said, I do remember that Korcan Hussein was working on a multimethods
library just a few weeks ago -- if that's still going on, I'd imagine that
it could make the implementation of comparison operators a little less
painful than manual double-dispatch.

Another alternative would be to throw an exception upon using * or ->
> on a default-constructed clone_ptr, though that would add yet more
> overhead to those operators.

True, and I personally do not enjoy working with operations that can
potentially throw or dereference null pointers,
especially with such seemingly simple and common
operations. Writing code is much easier when errors and exceptions are
avoided entirely by design
if possible.

-- 
-Matt Calabrese