From: Kevin Spinar (spinarkm_at_[hidden])
Date: 2006-07-09 21:37:55
On 7/9/06, Matt Calabrese <rivorus_at_[hidden]> wrote:
> What this all means is that < should not compare the internal pointer value,
> or rather, it shouldn't if you expect it to act correctly for the use that
> we are describing (as a smart object). The same logic holds
> true for other operations such as ==, !=, etc. Initially I was
> imagining that the operations wouldn't be defined at all, and
> if you wanted such functions you would have to do something like *left <
> *right, and if you wished to use them in standard containers and algorithms
> you would have to
> specify the sorting predicate rather than using the default less (you simply
> use an adapted predicate which performs the operation through a level
> of indirection).
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?
I agree with your logic, but I don't know if it's very practical to
implement clone_ptr this way.
> There is one more issue that I can see. Now that we are moving more towards
> the concept of a smart object, how is a null pointer handled, or rather,
> should it be allowable at all? Variants do not automatically allow a null
> state, so should a smart object follow suit?
> The problem with this is, in addition to the fact that some users may
> wish to have a nullable state, how
> do you default-construct the object? For instance, in the case of an
> abstract class, you wouldn't be able to default construct the type
> unless perhaps a default child type were specified via a template argument
> to the smart object type template itself (which would default to the first
> type if left unspecified).
> If the desire
> is there, perhaps both a "smart object" and a
> "nullable smart object" concept could be maintained (with the former being
> internally implemented with the latter),
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.
> On 7/9/06, Kevin Spinar <spinarkm_at_[hidden]> wrote:
> > Indeed. Perhaps poly_object?
> Sounds good to me. It could possibly even be shortened to poly_obj if it
> seems to long, though I don't know if "obj" is as immediately recognizable
> as meaning "object" as "ptr" is to "pointer."
I feel poly_obj would be rather recognizable.
Also, the clone_ptr library has been updated (
http://www.peltkore.net/~alipha/clone_ptr.html ): the
boost::*_pointer_cast functions have been implemented.
And loufoque, I didn't ignore your message; it just seemed that in
answering Matt's message, I also responded to your comments.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk