On 7/9/06, Kevin Spinar <spinarkm@gmail.com> 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