Rewriting clone() to return a boost::shared_ptr ? - C++ Language (Moderated)

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

Rewriting clone() to return a boost::shared_ptr ?
Goto page 1, 2 Next

C++Talk.NET Forum Index -> C++ Language (Moderated)

View previous topic :: View next topic

Author

Message

helix
Guest

Posted: Wed May 17, 2006 2:21 am Post subject: Rewriting clone() to return a boost::shared_ptr ?

Hi, Are there any issues relating to writing clone() so that it returns a smart pointer (e.g. boost::shared_ptr) rather than a raw pointer? For example, if I have a virtual base class, A, which exposes a clone function, and a class, B, which is dervied from A, will my 'smart' clone() do what I expect it to do ? class A { A(); virtual ~A(); virtual boost::shared_ptr<A> clone() const = 0; } class B : public A { B(); virtual ~B(); virtual boost::shared_ptr<A> clone() const; } boost::shared_ptr<A> B::clone() const { return boost::shared_ptr<A>(new B(*this)); } Thanks for you help, helix :) [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]

Alan Johnson
Guest

Posted: Wed May 17, 2006 10:21 am Post subject: Re: Rewriting clone() to return a boost::shared_ptr ?

helix wrote:

Quote:

Yes, that will work fine. There is, however, one drawback, in that you
cannot use covariant return types. Consider the following:

class A
{
public:
virtual A* clone() = 0;
};

class B
{
public:
virtual B* clone(); // Covariant return type.
};

There may be cases where you have a pointer to B, and you want to clone
the object to get another pointer to B, perhaps to do something through
some B specific member functions. Only pointers and references can be
covariant, however. Consider the following:

class A
{
public:
virtual boost::shared_ptr<A> clone() = 0;
};

class B
{
public:
virtual boost::shared_ptr<B> clone(); // Can't do this! Not a pointer.
};

--
Alan Johnson

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

kanze
Guest

Posted: Wed May 17, 2006 10:21 pm Post subject: Re: Rewriting clone() to return a boost::shared_ptr ?

helix wrote:

Quote:

Are there any issues relating to writing clone() so that it
returns a smart pointer (e.g. boost::shared_ptr) rather than a
raw pointer?

Just that it violates the usual conventions, and makes your
class harder to use. If you must use a smart pointer,
std::auto_ptr is the standard, but generally speaking, I would
say that clone() is a typical example where one expects a raw
pointer; how the caller wants to manage the object is his
business, and you have no right imposing anything special on
him.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Alan Johnson
Guest

Posted: Thu May 18, 2006 10:21 pm Post subject: Re: Rewriting clone() to return a boost::shared_ptr ?

Alan Johnson wrote:

Quote:

helix wrote:
Hi,

Are there any issues relating to writing clone() so that it returns a
smart pointer (e.g. boost::shared_ptr) rather than a raw pointer?

Yes, that will work fine. There is, however, one drawback, in that you
cannot use covariant return types.

It occurred to me that you could achieve the same benefits of covariant
types by using non-virtual member functions for your smart pointer
version of clone. These functions pass off the job of cloning to a
non-smart pointer version (which could be protected or private if you
don't want clients to be able to use it). Does anyone see any drawbacks
that perhaps I am missing?

In practice, I would expect this to be superior to relying on the client
to properly dispose of the cloned object, especially in a case where the
clone function lives in a dynamic library, and needs to be passed be
passed back to that library for deletion, which, if I understand
correctly, shared_ptr will do for you.

Example:

#include <boost/shared_ptr.hpp>

class A
{
public:
A() ;
virtual ~A() ;

virtual A * clone() = 0 ;

boost::shared_ptr<A> smart_clone()
{
return boost::shared_ptr<A>(this->clone()) ;
}
} ;

class B : public A
{
protected:
virtual B * clone() ; // covariant return type.
public:
B() ;
virtual ~B() ;

boost::shared_ptr<B> smart_clone() // fake covariance.
{
return boost::shared_ptr<B>(this->clone()) ;
}
} ;

--
Alan Johnson

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

David Abrahams
Guest

Posted: Thu May 18, 2006 10:21 pm Post subject: Re: Rewriting clone() to return a boost::shared_ptr ?

"kanze" <kanze@gabi-soft.fr> writes:

Quote:

helix wrote:

Are there any issues relating to writing clone() so that it
returns a smart pointer (e.g. boost::shared_ptr) rather than a
raw pointer?

Just that it violates the usual conventions, and makes your
class harder to use. If you must use a smart pointer,
std::auto_ptr is the standard, but generally speaking, I would
say that clone() is a typical example where one expects a raw
pointer; how the caller wants to manage the object is his
business, and you have no right imposing anything special on
him.

returning auto_ptr is much more responsible than returning a raw
pointer and it imposes nothing special because there's always
release().

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

helix
Guest

Posted: Thu May 18, 2006 11:21 pm Post subject: Re: Rewriting clone() to return a boost::shared_ptr ?

I can see how changing clone() to use smart pointers would violate the usual standard conventions, as well as causing confusion to other developers. Would you be happier if I provided two clone functions, one which returns a standard pointer and another which returns a smart pointer? As for auto_ptr, I generally stay well away as I can't store them in STL containers. IMHO this single fact renders it impractical in the real world - especially when you have boost's superior smart pointers available to you. I have to confess that I rarely use raw pointers any more, relying almost entirely on boost's smart pointers. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]

Axter
Guest

Posted: Thu May 18, 2006 11:21 pm Post subject: Re: Rewriting clone() to return a boost::shared_ptr ?

helix wrote:

Quote:

Hi,

Are there any issues relating to writing clone() so that it returns a
smart pointer (e.g. boost::shared_ptr) rather than a raw pointer? For
example, if I have a virtual base class, A, which exposes a clone
function, and a class, B, which is dervied from A, will my 'smart'
clone() do what I expect it to do ?

class A
{
A();
virtual ~A();
virtual boost::shared_ptr<A> clone() const = 0;
}

class B : public A
{
B();
virtual ~B();
virtual boost::shared_ptr<A> clone() const;
}

boost::shared_ptr<A> B::clone() const
{
return boost::shared_ptr<A>(new B(*this));
}

I recommend against using clone functions altogether, and instead use a
smart pointer that can handle cloning without requiring the target type
to have a clone function.
Consider using the following smart pointer which can do just that:
http://axter.com/smartptr

The clone function method requires more maintenance, and it's more
prone to bugs.
Consider what happens when a derived derived type gets added that
doesn't implement its own clone function.
When this happens, the object gets spliced.

For a more simplified version of the above smart pointer, check out the
copy_ptr:
http://axter.com/smartptr/copy__ptr_8hpp-source.htm
http://code.axter.com/copy_ptr.h

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

David Abrahams
Guest

Posted: Sat May 20, 2006 4:21 am Post subject: Re: Rewriting clone() to return a boost::shared_ptr ?

"helix" <andrew.j.line (AT) gmail (DOT) com> writes:

Quote:

I can see how changing clone() to use smart pointers would violate the
usual standard conventions, as well as causing confusion to other
developers. Would you be happier if I provided two clone functions,
one
which returns a standard pointer and another which returns a smart
pointer?

As for auto_ptr, I generally stay well away as I can't store them in
STL containers.

But you can convert them to shared_ptr. When you're just transferring
ownership (but not across DLL boundaries) and you don't necessarily
know what the receiver wants to do with the pointer, auto_ptr is
usually a better choice. It's cheaper and it lets you interact with
code that might expect to take ownership of a raw pointer. Once you
give ownership to a shared_ptr, you can never get it back.

Quote:

IMHO this single fact renders it impractical in the real world -
especially when you have boost's superior smart pointers available
to you. I have to confess that I rarely use raw pointers any more,
relying almost entirely on boost's smart pointers.

Boost's smart pointers are indeed great, but (for the most part) it's
not a matter of being superior to auto_ptr: they have different
purposes and characteristics. The Boost smart pointer designs
explicitly acknowledge the role of auto_ptr by including converting
constructors.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

kanze
Guest

Posted: Sat May 20, 2006 4:21 am Post subject: Re: Rewriting clone() to return a boost::shared_ptr ?

David Abrahams wrote:

Quote:

"kanze" <kanze@gabi-soft.fr> writes:

helix wrote:

Are there any issues relating to writing clone() so that it
returns a smart pointer (e.g. boost::shared_ptr) rather
than a raw pointer?

Just that it violates the usual conventions, and makes your
class harder to use. If you must use a smart pointer,
std::auto_ptr is the standard, but generally speaking, I
would say that clone() is a typical example where one
expects a raw pointer; how the caller wants to manage the
object is his business, and you have no right imposing
anything special on him.

returning auto_ptr is much more responsible than returning a
raw pointer and it imposes nothing special because there's
always release().

And boost::shared_ptr accepts it as a parameter to the
constructor as well, I think.

It depends. I'm not sure I see where it is more responsible; I
think it depends on the role of the actual object in the
application. Returning auto_ptr when you know that the caller
will absolutely have to use release, because the object's role
supposes an arbitrary lifetime (usually the case of entity
objects, for example) is not really a good idea. And in most of
the code I write, non-entity objects have value semantics, with
a copy constructor and an assignment operator, but no clone
function.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

kanze
Guest

Posted: Sat May 20, 2006 4:21 am Post subject: Re: Rewriting clone() to return a boost::shared_ptr ?

helix wrote:

Quote:

I can see how changing clone() to use smart pointers would
violate the usual standard conventions, as well as causing
confusion to other developers. Would you be happier if I
provided two clone functions, one which returns a standard
pointer and another which returns a smart pointer?

I can imagine cases where that might be appropriate. I think
the real question boils down to what the role of the object is
in the application, and why it is supporting clone(). If the
reason clone is being provided is to support transactions, for
example (so that you can roll back if necssary), it makes
absolutely no sense to return any smart pointer, in general.

Quote:

As for auto_ptr, I generally stay well away as I can't store
them in STL containers. IMHO this single fact renders it
impractical in the real world - especially when you have
boost's superior smart pointers available to you. I have to
confess that I rarely use raw pointers any more, relying
almost entirely on boost's smart pointers.

I tried that, and it didn't work. In my applications, most of
the dynamically allocated objects are entity objects, with
explicitly managed lifetimes. If all I counted on were boost's
smart pointers, I'd need to add some special function, like
dispose, to terminate the object lifetime, and deal with zombie
objects. And once I've added the necessary logic to ensure that
all other concerned objects are correctly notified when the
object's lifetime ends, a smart pointer doesn't add anything
except extra complications; IMHO, in such cases, it is much
easier to simply do "delete this" in the object function which
detects the condition, and use the destructor to propagate
notification. The equivalent using Boost would probably be to
maintain all of the objects in a collection (generally necessary
anyway), with a shared_ptr in the collection, and weak_ptr every
where else. To me, "delete this" just seems simpler and more
explicit that removing the object from the collection, and
counting on the side effect of removing it to call delete.

As for auto_ptr, it's true that you cannot put it in a standard
container. But it is very useful for managing the transition
between the moment you create the object, and the moment you've
transfered the object to whatever is responsible for managing
it. Dave Abrahams posted that using auto_ptr was a more
responsible approach, and I rapidly (too rapidly) posted a
counter argument -- the more I think about it, the more I think
he's right. When you don't know -- and don't want to know --
the actual mechanism handling lifetime, auto_ptr is the correct
transitional solution. In my example using transactions,
there's absolutely no reason to use smart pointers in general;
the transaction has to manage the pointers anyway, which objects
get deleted, and whether anything has to be done with them
before the delete, depends on whether the transaction has been
committed or not. But there is a small window of time between
the moment the copy has been created, and the moment the
transaction manager has effectively put it where ever it has to
be so that the destructor will find it correctly -- the
operation is not atomic. Some of the time, there will be no
possibility of an exception in that window of time, and the
auto_ptr doesn't serve any useful purpose. But Dave is right:
why worry about it? (And if the transaction manager is saving
the pointers in a standard container, a bad_alloc is always
possible -- unless you've installed a new_handler which aborts.)

If you do want to use boost::shared_ptr to manage the object, of
course, it has a constructor which takes an auto_ptr, so there's
no problem.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

James Kanze
Guest

Posted: Tue May 23, 2006 11:21 am Post subject: Re: Rewriting clone() to return a boost::shared_ptr ?

kanze wrote:

Quote:

David Abrahams wrote:
"kanze" <kanze@gabi-soft.fr> writes:

helix wrote:

Are there any issues relating to writing clone() so that it
returns a smart pointer (e.g. boost::shared_ptr) rather
than a raw pointer?

Just that it violates the usual conventions, and makes your
class harder to use. If you must use a smart pointer,
std::auto_ptr is the standard, but generally speaking, I
would say that clone() is a typical example where one
expects a raw pointer; how the caller wants to manage the
object is his business, and you have no right imposing
anything special on him.

returning auto_ptr is much more responsible than returning a
raw pointer and it imposes nothing special because there's
always release().

And boost::shared_ptr accepts it as a parameter to the
constructor as well, I think.

It depends. I'm not sure I see where it is more responsible; I
think it depends on the role of the actual object in the
application. Returning auto_ptr when you know that the caller
will absolutely have to use release, because the object's role
supposes an arbitrary lifetime (usually the case of entity
objects, for example) is not really a good idea. And in most of
the code I write, non-entity objects have value semantics, with
a copy constructor and an assignment operator, but no clone
function.

A follow-up to my own posting, but the more I think about it,
the more I think that David is right. I'm not sure I'd use the
word "responsible" -- a responsible programmer will take into
account local habits, conventions and coding guidelines as well.
But it is certainly safer. Even when the lifetime of the object
will be taken in hand by some external mechanism, there is a
small window of time between the return from clone() and the
moment when the object is fully in the hands of whatever is
finally responsible for managing it. And who knows what might
happen in that small window of time.

David's comments concerning release() are, in fact, right on
target. Once I have ensured that the object is fully and
correctly managed, I "express" this fact by calling release() on
the auto_ptr. And only then, not before.

--
James Kanze kanze.james (AT) neuf (DOT) fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Peter Dimov
Guest

Posted: Tue May 23, 2006 11:21 am Post subject: Re: Rewriting clone() to return a boost::shared_ptr ?

David Abrahams wrote:

Quote:

"helix" <andrew.j.line (AT) gmail (DOT) com> writes:

As for auto_ptr, I generally stay well away as I can't store them in
STL containers.

But you can convert them to shared_ptr. When you're just transferring
ownership (but not across DLL boundaries) and you don't necessarily
know what the receiver wants to do with the pointer, auto_ptr is
usually a better choice. It's cheaper and it lets you interact with
code that might expect to take ownership of a raw pointer. Once you
give ownership to a shared_ptr, you can never get it back.

IMHO this single fact renders it impractical in the real world -
especially when you have boost's superior smart pointers available
to you. I have to confess that I rarely use raw pointers any more,
relying almost entirely on boost's smart pointers.

Boost's smart pointers are indeed great, but (for the most part) it's
not a matter of being superior to auto_ptr: they have different
purposes and characteristics. The Boost smart pointer designs
explicitly acknowledge the role of auto_ptr by including converting
constructors.

To expand on that a little:

When the factory/clone function has a contractual obligation to create
the new object using 'new X', you should generally return an
auto_ptr<X> since it encodes this contract as part of its type. The
caller can now decide what to do with it as it is known that the
returned pointer can (needs to) be deleted at the end of the object
lifetime.

When the factory/clone function is free to choose the allocation and
disposal mechanisms, the proper return value is shared_ptr<X>, since it
takes care of the disposal without the caller needing to know anything
about it.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Peter Dimov
Guest

Posted: Tue May 23, 2006 11:21 am Post subject: Re: Rewriting clone() to return a boost::shared_ptr ?

kanze wrote:

Quote:

You can do that with shared_ptr if you really like to. (*) Your objects
need to store a shared_ptr to themselves as a member, and the 'delete
this' operation is performed by resetting this shared_ptr. You can leak
if you somehow lose all pointers to the object, of course. One upside
is that you can (and will, if you use weak_ptr) temporarily keep an
object alive until you are finished with it with a local shared_ptr
auto variable even if someone invokes 'delete_this' on it in the
meantime (not necessarily from the same thread).

(*) Seems to be a recurring pattern. :-)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

kanze
Guest

Posted: Wed May 24, 2006 4:21 pm Post subject: Re: Rewriting clone() to return a boost::shared_ptr ?

Peter Dimov wrote:

Quote:

kanze wrote:

I tried that, and it didn't work. In my applications, most
of the dynamically allocated objects are entity objects,
with explicitly managed lifetimes. If all I counted on were
boost's smart pointers, I'd need to add some special
function, like dispose, to terminate the object lifetime,
and deal with zombie objects. And once I've added the
necessary logic to ensure that all other concerned objects
are correctly notified when the object's lifetime ends, a
smart pointer doesn't add anything except extra
complications; IMHO, in such cases, it is much easier to
simply do "delete this" in the object function which detects
the condition, and use the destructor to propagate
notification. The equivalent using Boost would probably be
to maintain all of the objects in a collection (generally
necessary anyway), with a shared_ptr in the collection, and
weak_ptr every where else. To me, "delete this" just seems
simpler and more explicit that removing the object from the
collection, and counting on the side effect of removing it
to call delete.

You can do that with shared_ptr if you really like to. Your
objects need to store a shared_ptr to themselves as a member,
and the 'delete this' operation is performed by resetting this
shared_ptr.

I know it's possible, but what does it buy you, except
obfuscation? If I write "delete this", anyone familiar with C++
knows exactly what is going to happen. Resetting a shared_ptr
to trigger delete is IMHO a bit subtle, especially since it
counts on the fact of there not being another shared_ptr to the
same object. When I see shared_ptr, it says "shared" -- I find
it counter-intuitive to use it in cases where, by definition,
there is (or should be) only one owning pointer. Especially,
when there is no other need for that pointer.

Quote:

You can leak if you somehow lose all pointers to the object,
of course.

I don't see that as an objection, really, since we're not using
the pointer for memory management, but only to obfuscate a
delete this:-).

Seriously, in such cases, there will always be another pointer.
We're talking here about active entity objects, which react to
external events. And for the external event to find the object,
the object must be registered somewhere -- an event handler, a
database (e.g. std::map), etc. The constructor will normally
register it, and the destructor deregister it. In the simplest
cases, at least; in the case of multiple event handlers, it's
possible for the object to deregister from one, and to register
with another, according to its evolving state. And of course,
it's also possible in such cases to end up with an object that
will only be deleted when it processes an event it's not
registered for. Garbage collection with finalizers can help
here -- if you collect such a live object, it's a serious
program error. In the case of a data base (objects identified
by an external id), there are probably cases where keeping a
shared_ptr in the data base makes sense; instead of delete this,
you remove the object from the data base (so no one else can see
it).

Quote:

One upside is that you can (and will, if you use weak_ptr)
temporarily keep an object alive until you are finished with
it with a local shared_ptr auto variable even if someone
invokes 'delete_this' on it in the meantime (not necessarily
from the same thread).

Temporarily keeping an object alive when it is logically dead
(aka allowing access to a zombie object) is NOT what I would
call an upside. In transactional based systems, you will have
zombie objects within the transaction, in some cases, since you
cannot actually delete until the commit. Typically, however,
the only pointers to those objects should be in the transaction
manager, where no one else can see them, and the transaction
manager handles all of the object lifetime issues -- in a way
more complicated than shared_ptr would normally support.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

kanze
Guest

Posted: Wed May 24, 2006 4:21 pm Post subject: Re: Rewriting clone() to return a boost::shared_ptr ?

Peter Dimov wrote:

Quote:

When the factory/clone function has a contractual obligation
to create the new object using 'new X', you should generally
return an auto_ptr<X> since it encodes this contract as part
of its type. The caller can now decide what to do with it as
it is known that the returned pointer can (needs to) be
deleted at the end of the object lifetime.

When the factory/clone function is free to choose the
allocation and disposal mechanisms, the proper return value is
shared_ptr<X>, since it takes care of the disposal without the
caller needing to know anything about it.

When the factory/clone function is free to choose the allocation
and disposal mechanisms... is when? What do you mean by "free",
in this case? Or how much freedom?

I find a worrying tendancy here. I think that the correct
approach is to decide the object lifetime according to design
critera, and then program to the design. If shared_ptr fits
(and if often will, if for some reason you cannot use garbage
collection), fine, use it. If it doesn't, use something else.
But you shouldn't start out by deciding to use shared_ptr, and
then try and make the design fit. shared_ptr is an
implementation of one particular lifetime strategy; trying to
use it when that is not the lifetime strategy called for by the
design is confusing to who ever reads the code, even supposing
you manage to make it work. After all, the name is shared_ptr,
not do_anything_ptr (or simple ptr).

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Display posts from previous:

	C++Talk.NET Forum Index -> C++ Language (Moderated)	All times are GMT Goto page 1, 2 Next
Page 1 of 2

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum