Re: [boost] Preliminary release of clone_ptr library

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.

Kevin Spinar