If I have a factory, that creates an object and returns a pointer to it, what will be a better way to delete it:
By delete call in the "user" code, or by a new DestructObject function which I should have together with the factory?
In the general case, the factory might not use plain old new to allocate the object. It may use object and/or page pooling, malloc with placement new, or something even more exotic (memory mapping?). There are at least three ways to handle this that I can think of:
Have the factory supply a recycle method to be called when you are done with the object.
Return a smart pointer that knows how to do away with the object once no referers remain.
Implement a custom delete operator in the object itself.
I hesitate to recommend one over the other, since I haven't given it enough thought in the last five minutes to proffer a definitive opinion, but I would tend to favour the last option in combination with a regular smart pointer like boost/tr1::shared_ptr.
The best way to delete it manually would be not at all.
The following code provides an opportunity not to think about who should remove the newly created object.
class FooFactory
{
public:
static std::auto_ptr<Foo> CreateInstance();
};
// transmit ownership of created object from factory to 'a' variable
std::auto_ptr<Foo> a = FooFactory::CreateInstance();
// using the created object is not required
FooFactory::CreateInstance();
The most versatile solution for this problem is to derive your class from a base class that has a virtual "killing" function. Something like this:
class IDisposable {
public:
virtual void Release() = 0;
};
It's generally believed that polymorphic objects should have virtual destructors to support proper object cleanup. However this is incomplete, because it doesn't account for potentially different memory management of objects.
On the other hand this method doesn't require to use virtual destructors. It's now replaced by Release function that does both: invokation of the correct destructor and releasing the memory by the appropriate means.
takes care of the object destr
both: destruct
The object returned from the factory will implement this "interface".
Related
This specific case is for Arduino, but the question applies in general. The SDK provides a Client class, from which other classes (WiFiClient, EthernetClient, and others) derive.
In my own class I have a field of type Client* which can hold any of those derived classes. I'd like to be able to delete clientfield in my class (specifically in its destructor), but because Client does not provide a virtual destructor, that would cause undefined behaviour.
Any suggestions for ways to work around this?
I could Modify Client to add the destructor, but that's not ideal since anyone using my code would have to make that same change on their system.
All you need to do is cast the pointer to its actual derived type before deleting it, for example:
if (isWifiClient)
delete static_cast<WifiClient*>(clientfield);
else if (isEthernetClient)
delete static_cast<EthernetClient*>(clientfield);
If base class doesn't have virtual destructor, you have to delete it from pointer of it derived type.
Casting is one option:
// No need of `if` as deleting null pointers is noop.
delete dynamic_cast<WifiClient*>(client);
delete dynamic_cast<EthernetClient*>(client);
Better alternative is to use std::shared_ptr which handles the (type-erased) destructor.
std::shared_ptr<Client> client = std::make_shared<WifiClient>(/*..*/);
Note, "refactoring" to std::unique_ptr<Client> (as ownership is not shared for example) would lead to your original issue.
Can you use shared_ptr? It implements the dynamic dispatch in its deleter. It is important, though, that you allocate the correct shared_ptr type:
shared_ptr<Client> clientfield = make_shared<WifiClient>();
or
shared_ptr<Client> clientfield = shared_ptr<WifiClient>(new <WifiClient>());
This would be wrong:
shared_ptr<Client> clientfield(new <WifiClient>());
To make it correct again, you can pass a suitable deleter:
shared_ptr<Client> clientfield(new <WifiClient>(), default_delete<WifiClient>());
I've been thinking about the possible use of delete this in c++, and I've seen one use.
Because you can say delete this only when an object is on heap, I can make the destructor private and stop objects from being created on stack altogether. In the end I can just delete the object on heap by saying delete this in a random public member function that acts as a destructor. My questions:
1) Why would I want to force the object to be made on the heap instead of on the stack?
2) Is there another use of delete this apart from this? (supposing that this is a legitimate use of it :) )
Any scheme that uses delete this is somewhat dangerous, since whoever called the function that does that is left with a dangling pointer. (Of course, that's also the case when you delete an object normally, but in that case, it's clear that the object has been deleted). Nevertheless, there are somewhat legitimate cases for wanting an object to manage its own lifetime.
It could be used to implement a nasty, intrusive reference-counting scheme. You would have functions to "acquire" a reference to the object, preventing it from being deleted, and then "release" it once you've finished, deleting it if noone else has acquired it, along the lines of:
class Nasty {
public:
Nasty() : references(1) {}
void acquire() {
++references;
}
void release() {
if (--references == 0) {
delete this;
}
}
private:
~Nasty() {}
size_t references;
};
// Usage
Nasty * nasty = new Nasty; // 1 reference
nasty->acquire(); // get a second reference
nasty->release(); // back to one
nasty->release(); // deleted
nasty->acquire(); // BOOM!
I would prefer to use std::shared_ptr for this purpose, since it's thread-safe, exception-safe, works for any type without needing any explicit support, and prevents access after deleting.
More usefully, it could be used in an event-driven system, where objects are created, and then manage themselves until they receive an event that tells them that they're no longer needed:
class Worker : EventReceiver {
public:
Worker() {
start_receiving_events(this);
}
virtual void on(WorkEvent) {
do_work();
}
virtual void on(DeleteEvent) {
stop_receiving_events(this);
delete this;
}
private:
~Worker() {}
void do_work();
};
1) Why would I want to force the object to be made on the heap instead of on the stack?
1) Because the object's lifetime is not logically tied to a scope (e.g., function body, etc.). Either because it must manage its own lifespan, or because it is inherently a shared object (and thus, its lifespan must be attached to those of its co-dependent objects). Some people here have pointed out some examples like event handlers, task objects (in a scheduler), and just general objects in a complex object hierarchy.
2) Because you want to control the exact location where code is executed for the allocation / deallocation and construction / destruction. The typical use-case here is that of cross-module code (spread across executables and DLLs (or .so files)). Because of issues of binary compatibility and separate heaps between modules, it is often a requirement that you strictly control in what module these allocation-construction operations happen. And that implies the use of heap-based objects only.
2) Is there another use of delete this apart from this? (supposing that this is a legitimate use of it :) )
Well, your use-case is really just a "how-to" not a "why". Of course, if you are going to use a delete this; statement within a member function, then you must have controls in place to force all creations to occur with new (and in the same translation unit as the delete this; statement occurs). Not doing this would just be very very poor style and dangerous. But that doesn't address the "why" you would use this.
1) As others have pointed out, one legitimate use-case is where you have an object that can determine when its job is over and consequently destroy itself. For example, an event handler deleting itself when the event has been handled, a network communication object that deletes itself once the transaction it was appointed to do is over, or a task object in a scheduler deleting itself when the task is done. However, this leaves a big problem: signaling to the outside world that it no longer exists. That's why many have mentioned the "intrusive reference counting" scheme, which is one way to ensure that the object is only deleted when there are no more references to it. Another solution is to use a global (singleton-like) repository of "valid" objects, in which case any accesses to the object must go through a check in the repository and the object must also add/remove itself from the repository at the same time as it makes the new and delete this; calls (either as part of an overloaded new/delete, or alongside every new/delete calls).
However, there is a much simpler and less intrusive way to achieve the same behavior, albeit less economical. One can use a self-referencing shared_ptr scheme. As so:
class AutonomousObject {
private:
std::shared_ptr<AutonomousObject> m_shared_this;
protected:
AutonomousObject(/* some params */);
public:
virtual ~AutonomousObject() { };
template <typename... Args>
static std::weak_ptr<AutonomousObject> Create(Args&&... args) {
std::shared_ptr<AutonomousObject> result(new AutonomousObject(std::forward<Args>(args)...));
result->m_shared_this = result; // link the self-reference.
return result; // return a weak-pointer.
};
// this is the function called when the life-time should be terminated:
void OnTerminate() {
m_shared_this.reset( NULL ); // do not use reset(), but use reset( NULL ).
};
};
With the above (or some variations upon this crude example, depending on your needs), the object will be alive for as long as it deems necessary and that no-one else is using it. The weak-pointer mechanism serves as the proxy to query for the existence of the object, by possible outside users of the object. This scheme makes the object a bit heavier (has a shared-pointer in it) but it is easier and safer to implement. Of course, you have to make sure that the object eventually deletes itself, but that's a given in this kind of scenario.
2) The second use-case I can think of ties in to the second motivation for restricting an object to be heap-only (see above), however, it applies also for when you don't restrict it as such. If you want to make sure that both the deallocation and the destruction are dispatched to the correct module (the module from which the object was allocated and constructed), you must use a dynamic dispatching method. And for that, the easiest is to just use a virtual function. However, a virtual destructor is not going to cut it because it only dispatches the destruction, not the deallocation. The solution is to use a virtual "destroy" function that calls delete this; on the object in question. Here is a simple scheme to achieve this:
struct CrossModuleDeleter; //forward-declare.
class CrossModuleObject {
private:
virtual void Destroy() /* final */;
public:
CrossModuleObject(/* some params */); //constructor can be public.
virtual ~CrossModuleObject() { }; //destructor can be public.
//.... whatever...
friend struct CrossModuleDeleter;
template <typename... Args>
static std::shared_ptr< CrossModuleObject > Create(Args&&... args);
};
struct CrossModuleDeleter {
void operator()(CrossModuleObject* p) const {
p->Destroy(); // do a virtual dispatch to reach the correct deallocator.
};
};
// In the cpp file:
// Note: This function should not be inlined, so stash it into a cpp file.
void CrossModuleObject::Destroy() {
delete this;
};
template <typename... Args>
std::shared_ptr< CrossModuleObject > CrossModuleObject::Create(Args&&... args) {
return std::shared_ptr< CrossModuleObject >( new CrossModuleObject(std::forward<Args>(args)...), CrossModuleDeleter() );
};
The above kind of scheme works well in practice, and it has the nice advantage that the class can act as a base-class with no additional intrusion by this virtual-destroy mechanism in the derived classes. And, you can also modify it for the purpose of allowing only heap-based objects (as usually, making constructors-destructors private or protected). Without the heap-based restriction, the advantage is that you can still use the object as a local variable or data member (by value) if you want, but, of course, there will be loop-holes left to avoid by whoever uses the class.
As far as I know, these are the only legitimate use-cases I have ever seen anywhere or heard of (and the first one is easily avoidable, as I have shown, and often should be).
The general reason is that the lifetime of the object is determined by some factor internal to the class, at least from an application viewpoint. Hence, it may very well be a private method which calls delete this;.
Obviously, when the object is the only one to know how long it's needed, you can't put it on a random thread stack. It's necessary to create such objects on the heap.
It's generally an exceptionally bad idea. There are a very few cases- for example, COM objects have enforced intrusive reference counting. You'd only ever do this with a very specific situational reason- never for a general-purpose class.
1) Why would I want to force the object to be made on the heap instead of on the stack?
Because its life span isn't determined by the scoping rule.
2) Is there another use of delete this apart from this? (supposing that this is a legitimate use of it :) )
You use delete this when the object is the best placed one to be responsible for its own life span. One of the simplest example I know of is a window in a GUI. The window reacts to events, a subset of which means that the window has to be closed and thus deleted. In the event handler the window does a delete this. (You may delegate the handling to a controller class. But the situation "window forwards event to controller class which decides to delete the window" isn't much different of delete this, the window event handler will be left with the window deleted. You may also need to decouple the close from the delete, but your rationale won't be related to the desirability of delete this).
delete this;
can be useful at times and is usually used for a control class that also controls the lifetime of another object. With intrusive reference counting, the class it is controlling is one that derives from it.
The outcome of using such a class should be to make lifetime handling easier for users or creators of your class. If it doesn't achieve this, it is bad practice.
A legitimate example may be where you need a class to clean up all references to itself before it is destructed. In such a case, you "tell" the class whenever you are storing a reference to it (in your model, presumably) and then on exit, your class goes around nulling out these references or whatever before it calls delete this on itself.
This should all happen "behind the scenes" for users of your class.
"Why would I want to force the object to be made on the heap instead of on the stack?"
Generally when you force that it's not because you want to as such, it's because the class is part of some polymorphic hierarchy, and the only legitimate way to get one is from a factory function that returns an instance of a different derived class according to the parameters you pass it, or according to some configuration that it knows about. Then it's easy to arrange that the factory function creates them with new. There's no way that users of those classes could have them on the stack even if they wanted to, because they don't know in advance the derived type of the object they're using, only the base type.
Once you have objects like that, you know that they're destroyed with delete, and you can consider managing their lifecycle in a way that ultimately ends in delete this. You'd only do this if the object is somehow capable of knowing when it's no longer needed, which usually would be (as Mike says) because it's part of some framework that doesn't manage object lifetime explicitly, but does tell its components that they've been detached/deregistered/whatever[*].
If I remember correctly, James Kanze is your man for this. I may have misremembered, but I think he occasionally mentions that in his designs delete this isn't just used but is common. Such designs avoid shared ownership and external lifecycle management, in favour of networks of entity objects managing their own lifecycles. And where necessary, deregistering themselves from anything that knows about them prior to destroying themselves. So if you have several "tools" in a "toolbelt" then you wouldn't construe that as the toolbelt "owning" references to each of the tools, you think of the tools putting themselves in and out of the belt.
[*] Otherwise you'd have your factory return a unique_ptr or auto_ptr to encourage callers to stuff the object straight into the memory management type of their choice, or you'd return a raw pointer but provide the same encouragement via documentation. All the stuff you're used to seeing.
A good rule of thumb is not to use delete this.
Simply put, the thing that uses new should be responsible enough to use the delete when done with the object. This also avoids the problems with is on the stack/heap.
Once upon a time i was writing some plugin code. I believe i mixed build (debug for plugin, release for main code or maybe the other way around) because one part should be fast. Or maybe another situation happened. Such main is already released built on gcc and plugin is being debugged/tested on VC. When the main code deleted something from the plugin or plugin deleted something a memory issue would occur. It was because they both used different memory pools or malloc implementations. So i had a private dtor and a virtual function called deleteThis().
-edit- Now i may consider overloading the delete operator or using a smart pointer or simply just state never delete a function. It will depend and usually overloading new/delete should never be done unless you really know what your doing (dont do it). I decide to use deleteThis() because i found it easier then the C like way of thing_alloc and thing_free as deleteThis() felt like the more OOP way of doing it
When initializing a shared_ptr member variable:
// .h
class Customer
{
public:
Customer();
private:
std::shared_ptr<OtherClass> something_;
}
// .cpp
Customer():
something_(new OtherClass())
{
}
vs.
Customer():
something_(std::make_shared<OtherClass>())
{
}
Is the make_shared version allowed? I always seem to see the first version, which is preferred?
The only times when make_shared is not allowed are:
If you're getting a naked pointer allocated by someone else and storing it in shared_ptr. This is often the case when interfacing with C APIs.
If the constructor you want to call is not public (make_shared can only call public constructors). This can happen with factory functions, where you want to force users to create the object from the factory.
However, there are ways to get around this. Instead of having a private constructor, have a public constructor. But make the constructor take a type with can only be constructed by those with private access to the class. That way, the only people who can call make_shared with that object type are those with private access to the class.
So yes, you can do this.
In this case, using make_shared is not just allowed, but it is better to use it. If you use new, it will allocate memory for your Customer somewhere and then memory for your shared_ptr somewhere else, storing both strong and weak references (for weak pointers and shared pointers). If you use the make_shared you would have only one place in memory with everything and therefore only one new.
I'm not sure that I was really clear, this was the purpose of the GotW #89, read it, it is well explained there.
I've got a function inside a class (A) that essentially takes as a parameter a pointer to another class (B). The B class is inherited by multiple other classes which it should also accept.
What I would like to do is take ownership of this pointer to store for later use in the class, it won't be used outside the class again for anything else. While I would make the parameter a shared_ptr, I would like to avoid that as much as possible due to other people I work with who don't quite get the whole smart pointer thing. Is there any way to do this?
Here's a sort of example that I would like to do, although from what I've tested this doesn't work.
//In .h file
std::vector< unique_ptr< B > > data_store;
//In .cpp file
void A::add_data(B* NewItem)
{
data_store.resize(data_store.size()+1);
data_store[data_store.size()-1] = NewItem;
}
Second to that, I would like to maybe use a copy constructor or something similar to use a smart pointer inside the class: with what I'm having to do it could get a bit ugly if I have to do manual deletes. The problem with that is that I don't know whether it's the base class (B) coming in or whether it's a class that inherited from B. I'm not too sure how to deal with that without having to hard-code in some kind of checkable ID for the class and using the correct copy/move constructors, which I would like to avoid at all costs.
I'm using an updated Clang and libC++ from llvm which I updated about 10am UK time on 12th March 2012.
For any pointer that isn't supposed to be shared, which the class has sole ownership of the std::unique_ptr<T> is the correct choice. It will automatically delete the pointer when the owning object goes out of scope/is deleted. I would actually advice against using a shared pointer for this at all, as it would communicate to other developers that this member is supposed to be shared.
So for the copying. Since you have a pointer to an object which might have subclasses you need to use the clone idiom instead of a normal copy constructor. It is normally implemented by having a virtual clone function which returns a pointer (or a smart pointer) to the class. This requires all subclasses to reimplement this, returning a copy of itself.
class Base {
...
virtual std::unique_ptr<Base> clone() const = 0;
...
};
class Subclass {
...
virtual std::unique_ptr<Base> clone() const {
return std::unique_ptr<Base>(new Subclass(*this));
}
};
If the owning object has a copy constructor it will have to invoke this clone member function on the object it owns when creating a copy of itself.
If you wish to creater object, that owns vector of pointers you should use boost::vector_ptr. It automatically deletes all objects contained in itself
this is a question about which class does a free on shared pointers.
So I have a class hierarchy, base and derivedA and derivedB and derivedC all from base. Base has some virtual functions.
I have a class, Holder, it has a collection that holds instances of derivedA, derivedB and derivedC. So an instance of Holder is created, instances of the derived classes are dynamically created and add their pointers to the containers. I add the pointers so I can iterate through the container and call base->virtualFunction. I new the objects because otherwise an instance created on the stack is destroyed when it goes out of scope.
class Base;
class DerivedA : public base;
class DerivedB : public base;
class DerivedC : public base;
class Holder {
std::vector<Base*> collection;
void add(Base* base);
}
Holder holder;
DerivedA* da = new DerivedA;
DerivedB* db = new DerivedB;
holder.add(da);
holder.add(db);
who is to call delete on da and db?
Any other way to design this for the deletion concern goes away?
Thanks
Reza
My question is first off, which class should be responsible to free the dynamically created the derived classes? The class the contains the list
The simpler way ? Change your vector to become aware of ownership.
boost::ptr_vector<Base>
is such a vector, especially suited for polymorphic data:
deep-copy through clone methods (just implement virtual Base* clone() const;)
automatic memory management
sugar coating on dereferencing iterator (yields a Base& instead of a Base*)
In C++11, another alternative could be std::vector< std::unique_ptr<Base> >.
If you use new, then you have to say delete to clean up.
Your design suffers from the problem that you store the result of new, which you absolutely must keep track of, in a container, and it is unclear what can happen to it there. The container may be emptied or replaced or copied at some other point. In the end, you have to clean up, but how do you determine what to clean up?
Your design is inherently non-local, which means that the task of tracking the pointers now requires full understanding of everything that you do to the container. This is a heavy maintenance burden and limits scalability.
The better design approach would be to wrap the result of new into a single-responsibility manager like shared_ptr or unique_ptr and store those in the container. That way, it is always completely clear who owns the manually allocated objects and who disposes of them should the reference become inaccessible or lost.
[Original Update:] As a suggestion for your original design, which may or may not be appropriate (depending on many other factors you're not telling us about), and notwithstanding all its shortcomings, you could make the Holder do the cleaning up, and specify in the contract that you promise to add only pointers that you created with new:
Holder::~Holder() {
for (auto it = collection.cbegin(); it != collection.cend(); ++it)
delete *it;
}
This requires a strong contract between the class and the user, so do be sure that you intend this, that you document it, and most importantly that you write or delete copy constructors and assignment operators.
If you are going to for manual memory management, you need to define who is going to be responsible for deleting.
One possibility is for Holder to assume ownership of the classes and then to clean up in ~Holder (calling delete for every element in the vector). But then you would also need to decide on how Holder is going to be copied (deep copy or flat copy). The second option would require you to keep track of all HolderS that have references to the same memory etc.
Short and simple: Go with a shared_ptr or avoid this situation all together. Those are available in C++11 enabled compilers or from the Boost libraries.
The responsibility to free the memory is of the class/method that knows whether those objects are still used/useful.
In your simple example code Holder only contains pointers to the objects, so he can't possibly know when to free the memory: the pointed objects could be still useful even after Holder holder is disposed.
What you try to do has been implemented in a sane and proven way by Boost Smart Pointers, I strongly recommend always to first look at boost.org if this hasn't been done by it, already.
Basically, class-wise, the level you use the "new" is the level you use the "delete".
In your case the allocated vars in the program are in "main" I guess, so the allocation is not part of the class behavior therefor no class should free them but the user himself.