On 7/9/06, Matt Calabrese <rivorus@gmail.com> 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@gmail.com> 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