Consider the following situation:
SomeType *sptr = someFunction();
// do sth with sptr
I am unaware of the internals of someFunction(). Its pretty obvious that the pointer to the object which someFunction() is returning must be either malloc'ed or be a static variable.
Now, I do something with sptr, and quit. clearly the object be still on the heap which is possibly a source of leak.
How do I avoid this?
EDIT:
Are references more safer than pointers.
Do the destructor for SomeType would be called if I do :
{
SomeType &sref = *sptr;
}
Any insights.
You need to read the documentation on someFunction. someFunction needs to clearly define the ownership of the returned pointer (does the caller own it and need to call delete or does someFunction own it and will make sure the the object is destructed sometime in the future).
If the code does not document it's behavior, there is no safe way to use it.
What do you mean by quit? End the process? Your heap is usually destroyed when the process is destroyed. You would only get a leak potential after quitting the process if your asked the operating system to do something for you (like get a file or window handle) and didn't release it.
Also, functions that return pointers need to document very well whose responsibility it is to deallocate the pointer target (if at all), otherwise, you can't know whether you need to delete it yourself or you could delete it by accident (a disaster if you were not meant to do so).
If the documentation of the function doesn't tell you what to do, check the library documentation - sometimes a whole library takes the same policy rather than documenting it in each and every function. If you can't find the answer anywhere, contact the author or give up on the library, since the potential for errors is not worth it, IMHO.
In my experience most functions that return a pointer either allocate it dynamically or return a pointer that is based on the input parameter. In this case, since there are no arguments, I would bet that it is allocated dynamically and you should delete it when you're done. But programming shouldn't be a guessing game.
It's always a good habit to clean up after yourself, don't presume the OS will do it;
There's a good change your IDE or debugger will report memory leak when you quit your application.
What do you have to do ? Well, it depends, but normally you have to release the memory allocated by someFunction(), and the documentation will probably help you with that, either there's an API to release the memory or you have to do it manually with free or delete.
Max
The library should document this.
Either you delete it explicitly after use or you call some release method which makes sure that object (and any other resources it points to*) doesn't leak.
(given a choice) Unless its a huge (in terms of memory) object, I would rather prefer a return by value. Or pass a reference to the function.
If someFunction returns an object for me it should be normal to have a pair function like someFunctionFree which you'll call to release the resources of the SomeType object. All the things needed should be found in the documentation of someFunction (mainly how the object can be freed or if the object is automatically freed). I personally prefer the corresponding deallocation function (a CreateObject/DestroyObject pair).
As others note it's up to the function to enforce it's ownership assumptions in code. Here's one way to do that using what's known as smart pointers:
#include <iostream>
#include <boost/shared_ptr.hpp>
struct Foo
{
Foo( int _x ) : x(_x) {}
~Foo() { std::cout << "Destructing a Foo with x=" << std::hex << x << "\n"; }
int x;
};
typedef boost::shared_ptr<Foo> FooHandle;
FooHandle makeFoo(int _x = 0xDEADBEEF) {
return FooHandle(new Foo(_x));
}
int main()
{
{
FooHandle fh = makeFoo();
}
std::cout<<"No memory leaks here!\n";
return 0;
}
Related
How should we delete a static pointer of a class which is pointing to itself ? How to write destructor for this?
PS: I am just trying this out of curiosity.
#include <iostream>
class rest
{
static rest *own;
public:
int x;
rest(int x) : x(x)
{
std::cout << "creating rest object";
}
~rest()
{
std::cout << "destructor";
}
static void set(rest *setOwn)
{
own = setOwn;
}
};
rest *rest::own = NULL;
int main()
{
rest *x = new rest(1);
rest *y = new rest(2);
rest::set(y);
delete x // Consider there will be only one object x and as soon as x gets deleted, I want to delete static class object(own) as well.
When you write code in C++ you have to think about lifetime. That decision is up to you, as a programmer.
By far the easiest way to think about lifetime is to phrase it in terms of ownership; blocks of code (or objects) "own" the lifetime of resources. When the block of code ends, of the object is destroyed, it frees the resource.
That resource can, in turn, be an object that could free further resources.
This is not the only way to think about ownership.
In your case, because own is a static variable, there is no clear owner.
So you have more work to do.
Your responsibility is to ensure that the resource that own points to is cleaned up after nobody else needs it (the dangling pointer problem, but before you lose track of it (the leak problem).
If you rewrite your code in terms of RAII and the Rule of 5/0, then this becomes easy. If you don't, then you have to prove your code correct using a bunch of work.
You can have programs where the resource ownership problem is a Turing complete one that you have proved to yourself does not result in dangling pointers or leaks. And in theory the problem you are trying to solve could be so hard you have no choice but to make an insane resource lifetime system like that.
I don't know your real problem, so I cannot tell you how you should solve your resource lifetime issue.
But 99% of the time, you should rewrite your code to be RAII and rule of 5/0 friendly.
I am trying to print on which line addref and release is called.Here is code
In code below I have created on ReferenceCount class whose main functionality to increase and decrease refernce count.
Referencemanager class keeps track of reference count and deletes the object once it reaches 0.
Test1 is test class .In main I am creating Test1 pointer and wrapping it with CReferenceManager class. Now during creation of CReferenceManager class AddRef is called and while destruction Release would be called.
If there is memory leak then it would be easier to detect if I can print out FILE and LINE numbers when AddRef and Release called with reference counts at that point.
If there a way that I can print FILE and LINE number from where AddRef and Release gets called. One way is that I can overwrite AddRef and Release in derived classes and prinf FILE and LINE numbers
//ReferenceCount.h
#include <string>
#include <Windows.h>
using namespace std;
class CReferenceCount
{
public:
CReferenceCount();
virtual ~CReferenceCount();
virtual void AddRef();
virtual bool Release();
private:
LONG m_ref;
};
// RefCount.cpp
//
#include "stdafx.h"
#include "ReferenceCount.h"
CReferenceCount::CReferenceCount():m_ref(0)
{
AddRef();
}
CReferenceCount::~CReferenceCount()
{
}
void CReferenceCount::AddRef()
{
InterlockedIncrement(&m_ref);
}
bool CReferenceCount::Release()
{
if (InterlockedDecrement(&m_ref) == 0)
{
delete this;
return true;
}
return false;
}
//ReferenceManager.h
#include <string>
#include <Windows.h>
using namespace std;
class CReferenceCount
{
public:
CReferenceCount();
virtual ~CReferenceCount();
virtual void AddRef();
virtual bool Release();
private:
LONG m_ref;
};
//test.cpp
#include "stdafx.h"
#include "ReferenceCount.h"
#include "RefManager.h"
#include <iostream>
using namespace std;
class Test1: public CReferenceCount
{
public:
Test1(){}
~Test1(){}
private :
int m_i;
};
void main()
{
Test1 *pTest= new Test1();
CReferenceManager<Test1> testRef(pTest);
}
Similare questions I have posted
finding who creates object via smart pointer
Design pattern to detect memory leaks for reference counted smart pointers
but non of the answers give right explanation to tackle this proble,
The only way is to define macros for calling AddRef and Release, since there is no way for the functions to know internally from where they are being called. So you could use something like.
#define RELEASE(obj) cout << __LINE__ << ":" << __FILE__ << endl; (obj).Release();
Also, different compilers have different pre-defined macros; if portability is a concern, it's something you should look into when writing code like the above. MSDN reference (2003)
Given your comments below, i might offer another somewhat hackish solution. You may not be able to see where your reference is being released, but you can get more information about where it was created, and which are not being released properly.
template <typename T>
struct CReferenceManager
{
CReferenceManager(const T & _obj, const string & _file, int _line) : mObj(_obj), mFile(_file), mLine(_line)
{
cout << "Constructing from " << _file << ":" << _line << endl;
CReferenceManager::sObjects[make_pair(mFile, mLine)]++;
mObj.addRef();
}
~CReferenceManager()
{
cout << "Destructing object created at " << mFile << ":" << mLine << endl;
CReferenceManager::sObjects[make_pair(mFile, mLine)]--;
mObj.Release();
}
static map<pair<string, int>, int> sObjects;
string mFile;
int mLine;
T obj;
}
int main()
{
...
// Cycle through sObjects before return, note any unreleased entries
return 0;
}
Note this is just pseudo-code; I doubt it compiles or works out of the box!
You should never allocate or release references explicitly in your own code, so storing the source file and line where references are incremented or decremented isn't going to help you at all, since those will (should!) always be inside the reference counting management code.
You did not include the source code to your CReferenceManager class, but based on your description it is a wrapper to a referenced counted object. Is this correct? The correct implementation of this CReferenceManager object should ensure that:
a constructor that takes a naked pointer stores the pointer and does not change the reference count (since your CReferenceCount class creates object with one reference)
reference is always decremented in the destructor
reference is incremented in the copy-constructor
reference for the right side object is incremented, and reference for the left side object is decremented in the assignment operator
no explicit increment/decrement reference methods should be exposed
the operator->() method should return the pointer to the object
there should be no direct way to detach the reference counted object from a CReferenceManager instance that owns it. The only way is via assignment of a new reference counted object.
Also, you'd want to make the AddRef() and Release() methods in your CReferenceCount class private, and make them accessible only to the CReferenceManager class via class friendship.
If you follow the above rules in your CReferenceManager class, then you can avoid leaks or other memory problems by ensuring that everybody accesses the object via a CReferenceManager wrapper allocated on the stack. In other words:
To create a new referenced counted object, passed a newly created object (with one reference) to a stack allocated CReferenceManager object. Example:
CReferenceManager<Test1> testRef(new Test1());
To pass the object as an argument to another function or method, always pass a CReferenceManager object by value (not by reference, and not by pointer). If you do it this way the copy constructor and the destructor will take care of maintaining the reference counts for you. Example:
void someFunction(CReferenceManager<Test1> testObj)
{
// use testObj as if it was a naked pointer
// reference mananagement is automatically handled
printf("some value: %d\n", testObj->someValue());
}
int main()
{
CReferenceManager<Test1> testRef(new Test1());
someFunction(testRef);
}
If you need to stick the reference counted object in a container, then insert a CReferenceManager wrapper by value (not its pointer, and not the object's naked pointer). Example:
std::vector< CReferenceManager<Test1> > myVector;
CReferenceManager<Test1> testRef(new Test1());
myVector.push_back(testRef);
myVector[0]->some_method(); // invoke the object as if it was a pointer!
I believe if you strictly follow the above rules the only problems you will find are bugs in your reference counting implementation.
An example implementation that follows these rules is in this page, though that solution lacks any support for multi-threading protection.
I hope this helps!
There is some way of doing this, but first let me ask you one thing. Why you want to manage references by hand and provide an opportunity for memory leaks? you can easily use boost::intrusive_ptr to do the job for you?( if you don't want the boost, there is no problem, see implementation of intrusive_ptr and implement your own class or just copy it to your own file ) and then you don't have a memory leak to search for it!!
But as an answer for your question you could have 2 AddRef/Release one for debug version and another for release and you should add AddRef positions to an structure like std::stack and on Release pop them from stack and at very end you see how much references from witch positions remained in the stack! but if this is for COM implementation remember that COM may call AddRef multiple time and then remove them at later time and thus you can't understand which AddRef have no corresponding Release.
For the projects I am involved in I had similar needs. We have our own smart-pointer template class and from time to time memory leaks appeared due to circular references.
To know which smart-pointer referencing a leaked object still is alive (2 or more), we compile the sources with a special pre-processor define which enables special debugging code in the smart-pointer implementation. You can have a look at our smart-pointer class.
In essence, each smart-pointer and reference counted object get a unique id. When we get the id for the leaked object (usually using valgrind to identify the source location of the memory allocation for the leaked object), we use our special debugging code to get all smart-pointer ids which reference the object. Then we use a configuration file where we write down the smart-pointer ids and at next application start-up, this file is read by our debugging tool which then knows for which newly created smart-pointer instance it should trigger a signal for entering the debugger. This reveals the stack trace where that smart-pointer instance was created.
Admittedly, this involves some work and might only pay off for larger projects.
Another possibility would be to record a stack trace inside your AddRef method at runtime. Have a look at my ctkBackTrace class to create a stack trace at runtime. It should be easy to replace the Qt specific types by standard STL types.
I guess that with a bit of work and using libunwind you could probably try to get what you need (which would be a really appreciated).
http://www.nongnu.org/libunwind/docs.html
The principle of reference counting is to increase the counter when the user link to the object and to decrease when they break the link.
So you have to:
manipulate smart pointers, not pointers to make increase/decrease transparent
overload copy constructor and assign operator of the smart_pointer
Symbolic exemple:
A a = new A(); refcount = 0, nobody use it
Link<A> lnk( a ); refcount = 1
obj.f( lnk ); obj stores lnk, refcount = 2
this method may returns since the ownership has been transfered to obj
So, take a look at parameter passing (may do automatic copies) and at copy into foreign objects.
Good tutorials exists on that in the CORBA nebulae.
You may see also ACE or ICE, or 0MQ.
One way to do what you asked, is to pass AddRef and Release this information using something like this:
void CReferenceCount::AddRef(const char *file=0, int line=-1) { if (file) cout << "FILE:" << file; if (line>0) count << " LINE: " << line; .... do the rest here ... }
Then when you call the function, you can use a macro similar to what Rollie suggested above, like this:
#define ADDREF(x) x.AddRef(__FILE__, __LINE__)
This will pass the file and line where the call is made, which I believe is what you asked for. You can control what you want to do with the information within the methods. Printing them out, as I did above, is just an example. You may want to collect more information beyond this, and log it to another object, so you have a history of your calls, write them to a log file, etc. You may also pass more information from the call points than just the file and line, according to the type and level of tracking you need. The default parameters also allow you to use them without passing anything (by a simple macro redefinition), just to see how the final version will behave, with the overhead of two stack pushes and two condition checks.
Short answer: you should use the ideas that others posted, namely making use of ADD/RELEASE macros and passing the predefined __FILE__ and __LINE__ macros that the compiler provides to your tracking class.
Slightly longer answer: You can also use functionality that allows you to walk the stack and see who called the function, which is somewhat more flexible and clean than using macros, but almost certainly slower.
This page shows you how to achieve this when using GCC: http://tombarta.wordpress.com/2008/08/01/c-stack-traces-with-gcc/.
In Windows you can use some compiler intrinsics along with symbol-lookup functionality. For details check out: http://www.codeproject.com/tools/minidump.asp
Note that in both cases your program would need to include at least some symbols for this to work.
Unless you have special requirements for doing this at runtime, I'd suggest you check out the short answer.
This question already has answers here:
How can I determine if a C++ object has been deallocated?
(6 answers)
Closed 4 years ago.
Consider this program:
int main()
{
struct test
{
test() { cout << "Hello\n"; }
~test() { cout << "Goodbye\n"; }
void Speak() { cout << "I say!\n"; }
};
test* MyTest = new test;
delete MyTest;
MyTest->Speak();
system("pause");
}
I was expecting a crash, but instead this happened:
Hello
Goodbye
I say!
I'm guessing this is because when memory is marked as deallocated it isn't physically wiped, and since the code references it straight away the object is still to be found there, wholly intact. The more allocations made before calling Speak() the more likely a crash.
Whatever the reason, this is a problem for my actual, threaded code. Given the above, how can I reliably tell if another thread has deleted an object that the current one wants to access?
There is no platform-independent way of detecting this, without having the other thread(s) set the pointer to NULL after they've deleted the object, preferably inside a critical section, or equivalent.
The simple solution is: design your code so that this can't occur. Don't delete objects that might be needed by other threads. Clear up shared resource only once it's safe.
I was expecting a crash, but instead
this happened:
That is because Speak() is not accessing any members of the class. The compiler does not validate pointers for you, so it calls Speak() like any other function call, passing the (deleted) pointer as the hidden 'this' parameter. Since Speak() does not access that parameter for anything, there is no reason for it to crash.
I was expecting a crash, but instead this happened:
Undefined Behaviour means anything can happen.
Given the above, how can I reliably tell if another thread has deleted an object that the current one wants to access?
How about you set the MyTest pointer to zero (or NULL). That will make it clear to other threads that it's no longer valid. (of course if your other threads have their own pointers pointing to the same memory, well, you've designed things wrong. Don't go deleting memory that other threads may use.)
Also, you absolutely can't count on it working the way it has. That was lucky. Some systems will corrupt memory immediately upon deletion.
Despite it's best to improve the design to avoid access to a deleted object, you can add a debug feature to find the location where you access deleted objects.
Make all methods and the destructor virtual.
Check that your compiler creates an object layout where the pointer to
the vtable is in front of the object
Make the pointer to the vtable invalid in the destructor
This dirty trick causes that all functions calls reads the address where the pointer points to and cause a NULL pointer exception on most systems. Catch the exception in the debugger.
If you hesitate to make all methods virtual, you can also create an abstract base class and inherit from this class. This allows you to remove the virtual function with little effort. Only the destructor needs to be virtual inside the class.
example
struct Itest
{
virtual void Speak() = 0;
virtual void Listen() = 0;
};
struct test : public Itest
{
test() { cout << "Hello\n"; }
virtual ~test() {
cout << "Goodbye\n";
// as the last statement!
*(DWORD*)this = 0; // invalidate vtbl pointer
}
void Speak() { cout << "I say!\n"; }
void Listen() { cout << "I heard\n"; }
};
You might use reference counting in this situation. Any code that dereferences the pointer to the allocated object will increment the counter. When it's done, it decrements. At that time, iff the count hits zero, deletion occurs. As long as all users of the object follow the rules, nobody access the deallocated object.
For multithreading purposes I agree with other answer that it's best to follow design principles that don't lead to code 'hoping' for a condition to be true. From your original example, were you going to catch an exception as a way to tell if the object was deallocated? That is kind of relying on a side effect, even if it was a reliable side effect which it's not, which I only like to use as a last resort.
This is not a reliable way to "test" if something has been deleted elsewhere because you are invoking undefined behavior - that is, it may not throw an exception for you to catch.
Instead, use std::shared_ptr or boost::shared_ptr and count references. You can force a shared_ptr to delete it's contents using shared_ptr::reset(). Then you can check if it was deleted later using shared_ptr::use_count() == 0.
You could use some static and runtime analyzer like valgrind to help you see these things, but it has more to do with the structure of your code and how you use the language.
// Lock on MyTest Here.
test* tmp = MyTest;
MyTest = NULL;
delete tmp;
// Unlock MyTest Here.
if (MyTest != NULL)
MyTest->Speak();
One solution, not the most elegant...
Place mutexes around your list of objects; when you delete an object, mark it as null. When you use an object, check for null. Since access is serialized, you'll have a consistent operation.
Today, without much thought, I wrote a simple function return to a char* based on a switch statement of given enum values. This, however, made me wonder how I could release that memory. What I did was something like this:
char* func()
{
char* retval = new char[20];
// Switch blah blah - will always return some value other than NULL since default:
return retval;
}
I apologize if this is a naive question, but what is the best way to release the memory seeing as I cannot delete the memory after the return and, obviously, if I delete it before, I won't have a returned value. What I was thinking as a viable solution was something like this
void func(char*& in)
{
// blah blah switch make it do something
}
int main()
{
char* val = new char[20];
func(val);
// Do whatever with func (normally func within a data structure with specific enum set so could run multiple times to change output)
delete [] val;
val = NULL;
return 0;
}
Would anyone have anymore insight on this and/or explanation on which to use?
Regards,
Dennis M.
You could write such functions in pair, like
Xyz* CreateXyz();
void DestroyXyz(Xyz *xyz);
Abc* NewAbc();
void DeleteAbc(Abc *abc);
Or you simply can transfer the responsibilty of deleting Xyz/Abc to the clients, i.e ones who call the function must also do delete on the returned object after using it.
Whatever you choose, make it clear in your documentation how the created object should be destroyed.
I would prefer pair-functions, especially if there is lot of things to consider before deleting!
By the way, you should prefer using std::string, instead of char*. Make use of STL as much as you can. They can solve most of your problems! The above advice is for situations where STL doesn't fit! In general, prefer STL!
Have you considered using an STL type or other class instead of returning a raw pointer? For instance, if your char * is a string, use std::string instead and avoid any risk of leaks:
std::string func()
{
std::string retval("");
// Switch blah blah - will always return some value other than NULL since default:
return retval;
}
If you plan to return raw pointers from a function, you must make really clear on the documentation whose is the responsibility of deleting the pointer, i.e. who owns it. In this case, you should state explicitly that the pointer ownership is transferred to the caller, who is responsible to delete it.
Although many people are OK with just specifying the ownership in the documentation, often it's better to enforce this policy in the code. In particular, smart pointers are often used for this: the current C++ standard provides the std::auto_ptr, a smart pointer which transfers ownership on copy, i.e. when you return it to the caller, you're transferring the ownership to the target std::auto_ptr. Notice that std::auto_ptr automagically deletes the pointed memory on its destruction if it still owns it. The upcoming C++ standard provides std::unique_ptr that works in a similar fashion, but using move semantic.
Unfortunately, std::auto_ptr isn't thought for arrays (which need delete [] instead of delete), so you cannot use for your your purpose. I think that the decision of not including an auto_ptr for arrays was made deliberately, because the STL already provides all the containers you may need if you need to return a collection of items which handle by their own memory management and copy.
In particular, for strings you should simply use std::string and forget completely about this kind of memory management and pointer ownership problems.
In this case whoever calls the func() should release the memory when its not needed. But the correct deletion happens like this:
delete val;
val = NULL;
What are some ways you can shoot yourself in the foot when using boost::shared_ptr? In other words, what pitfalls do I have to avoid when I use boost::shared_ptr?
Cyclic references: a shared_ptr<> to something that has a shared_ptr<> to the original object. You can use weak_ptr<> to break this cycle, of course.
I add the following as an example of what I am talking about in the comments.
class node : public enable_shared_from_this<node> {
public :
void set_parent(shared_ptr<node> parent) { parent_ = parent; }
void add_child(shared_ptr<node> child) {
children_.push_back(child);
child->set_parent(shared_from_this());
}
void frob() {
do_frob();
if (parent_) parent_->frob();
}
private :
void do_frob();
shared_ptr<node> parent_;
vector< shared_ptr<node> > children_;
};
In this example, you have a tree of nodes, each of which holds a pointer to its parent. The frob() member function, for whatever reason, ripples upwards through the tree. (This is not entirely outlandish; some GUI frameworks work this way).
The problem is that, if you lose reference to the topmost node, then the topmost node still holds strong references to its children, and all its children also hold a strong reference to their parents. This means that there are circular references keeping all the instances from cleaning themselves up, while there is no way of actually reaching the tree from the code, this memory leaks.
class node : public enable_shared_from_this<node> {
public :
void set_parent(shared_ptr<node> parent) { parent_ = parent; }
void add_child(shared_ptr<node> child) {
children_.push_back(child);
child->set_parent(shared_from_this());
}
void frob() {
do_frob();
shared_ptr<node> parent = parent_.lock(); // Note: parent_.lock()
if (parent) parent->frob();
}
private :
void do_frob();
weak_ptr<node> parent_; // Note: now a weak_ptr<>
vector< shared_ptr<node> > children_;
};
Here, the parent node has been replaced by a weak pointer. It no longer has a say in the lifetime of the node to which it refers. Thus, if the topmost node goes out of scope as in the previous example, then while it holds strong references to its children, its children don't hold strong references to their parents. Thus there are no strong references to the object, and it cleans itself up. In turn, this causes the children to lose their one strong reference, which causes them to clean up, and so on. In short, this wont leak. And just by strategically replacing a shared_ptr<> with a weak_ptr<>.
Note: The above applies equally to std::shared_ptr<> and std::weak_ptr<> as it does to boost::shared_ptr<> and boost::weak_ptr<>.
Creating multiple unrelated shared_ptr's to the same object:
#include <stdio.h>
#include "boost/shared_ptr.hpp"
class foo
{
public:
foo() { printf( "foo()\n"); }
~foo() { printf( "~foo()\n"); }
};
typedef boost::shared_ptr<foo> pFoo_t;
void doSomething( pFoo_t p)
{
printf( "doing something...\n");
}
void doSomethingElse( pFoo_t p)
{
printf( "doing something else...\n");
}
int main() {
foo* pFoo = new foo;
doSomething( pFoo_t( pFoo));
doSomethingElse( pFoo_t( pFoo));
return 0;
}
Constructing an anonymous temporary shared pointer, for instance inside the arguments to a function call:
f(shared_ptr<Foo>(new Foo()), g());
This is because it is permissible for the new Foo() to be executed, then g() called, and g() to throw an exception, without the shared_ptr ever being set up, so the shared_ptr does not have a chance to clean up the Foo object.
Be careful making two pointers to the same object.
boost::shared_ptr<Base> b( new Derived() );
{
boost::shared_ptr<Derived> d( b.get() );
} // d goes out of scope here, deletes pointer
b->doSomething(); // crashes
instead use this
boost::shared_ptr<Base> b( new Derived() );
{
boost::shared_ptr<Derived> d =
boost::dynamic_pointer_cast<Derived,Base>( b );
} // d goes out of scope here, refcount--
b->doSomething(); // no crash
Also, any classes holding shared_ptrs should define copy constructors and assignment operators.
Don't try to use shared_from_this() in the constructor--it won't work. Instead create a static method to create the class and have it return a shared_ptr.
I've passed references to shared_ptrs without trouble. Just make sure it's copied before it's saved (i.e., no references as class members).
Here are two things to avoid:
Calling the get() function to get the raw pointer and use it after the pointed-to object goes out of scope.
Passing a reference of or a raw pointer to a shared_ptr should be dangerous too, since it won't increment the internal count which helps keep the object alive.
We debug several weeks strange behavior.
The reason was:
we passed 'this' to some thread workers instead of 'shared_from_this'.
Not precisely a footgun, but certainly a source of frustration until you wrap your head around how to do it the C++0x way: most of the predicates you know and love from <functional> don't play nicely with shared_ptr. Happily, std::tr1::mem_fn works with objects, pointers and shared_ptrs, replacing std::mem_fun, but if you want to use std::negate, std::not1, std::plus or any of those old friends with shared_ptr, be prepared to get cozy with std::tr1::bind and probably argument placeholders as well. In practice this is actually a lot more generic, since now you basically end up using bind for every function object adaptor, but it does take some getting used to if you're already familiar with the STL's convenience functions.
This DDJ article touches on the subject, with lots of example code. I also blogged about it a few years ago when I first had to figure out how to do it.
Using shared_ptr for really small objects (like char short) could be an overhead if you have a lot of small objects on heap but they are not really "shared". boost::shared_ptr allocates 16 bytes for every new reference count it creates on g++ 4.4.3 and VS2008 with Boost 1.42. std::tr1::shared_ptr allocates 20 bytes. Now if you have a million distinct shared_ptr<char> that means 20 million bytes of your memory are gone in holding just count=1. Not to mention the indirection costs and memory fragmentation. Try with the following on your favorite platform.
void * operator new (size_t size) {
std::cout << "size = " << size << std::endl;
void *ptr = malloc(size);
if(!ptr) throw std::bad_alloc();
return ptr;
}
void operator delete (void *p) {
free(p);
}
Giving out a shared_ptr< T > to this inside a class definition is also dangerous.
Use enabled_shared_from_this instead.
See the following post here
You need to be careful when you use shared_ptr in multithread code. It's then relatively easy to become into a case when couple of shared_ptrs, pointing to the same memory, is used by different threads.
The popular widespread use of shared_ptr will almost inevitably cause unwanted and unseen memory occupation.
Cyclic references are a well known cause and some of them can be indirect and difficult to spot especially in complex code that is worked on by more than one programmer; a programmer may decide than one object needs a reference to another as a quick fix and doesn't have time to examine all the code to see if he is closing a cycle. This hazard is hugely underestimated.
Less well understood is the problem of unreleased references. If an object is shared out to many shared_ptrs then it will not be destroyed until every one of them is zeroed or goes out of scope. It is very easy to overlook one of these references and end up with objects lurking unseen in memory that you thought you had finished with.
Although strictly speaking these are not memory leaks (it will all be released before the program exits) they are just as harmful and harder to detect.
These problems are the consequences of expedient false declarations: 1. Declaring what you really want to be single ownership as shared_ptr. scoped_ptr would be correct but then any other reference to that object will have to be a raw pointer, which could be left dangling. 2. Declaring what you really want to be a passive observing reference as shared_ptr. weak_ptr would be correct but then you have the hassle of converting it to share_ptr every time you want to use it.
I suspect that your project is a fine example of the kind of trouble that this practice can get you into.
If you have a memory intensive application you really need single ownership so that your design can explicitly control object lifetimes.
With single ownership opObject=NULL; will definitely delete the object and it will do it now.
With shared ownership spObject=NULL; ........who knows?......
If you have a registry of the shared objects (a list of all active instances, for example), the objects will never be freed. Solution: as in the case of circular dependency structures (see Kaz Dragon's answer), use weak_ptr as appropriate.
Smart pointers are not for everything, and raw pointers cannot be eliminated
Probably the worst danger is that since shared_ptr is a useful tool, people will start to put it every where. Since plain pointers can be misused, the same people will hunt raw pointers and try to replace them with strings, containers or smart pointers even when it makes no sense. Legitimate uses of raw pointers will become suspect. There will be a pointer police.
This is not only probably the worst danger, it may be the only serious danger. All the worst abuses of shared_ptr will be the direct consequence of the idea that smart pointers are superior to raw pointer (whatever that means), and that putting smart pointers everywhere will make C++ programming "safer".
Of course the mere fact that a smart pointer needs to be converted to a raw pointer to be used refutes this claim of the smart pointer cult, but the fact that the raw pointer access is "implicit" in operator*, operator-> (or explicit in get()), but not implicit in an implicit conversion, is enough to give the impression that this is not really a conversion, and that the raw pointer produced by this non-conversion is an harmless temporary.
C++ cannot be made a "safe language", and no useful subset of C++ is "safe"
Of course the pursuit of a safe subset ("safe" in the strict sense of "memory safe", as LISP, Haskell, Java...) of C++ is doomed to be endless and unsatisfying, as the safe subset of C++ is tiny and almost useless, as unsafe primitives are the rule rather than the exception. Strict memory safety in C++ would mean no pointers and only references with automatic storage class. But in a language where the programmer is trusted by definition, some people will insist on using some (in principle) idiot-proof "smart pointer", even where there is no other advantage over raw pointers that one specific way to screw the program state is avoided.