Boost shared pointers - Revision history

PBS: Move to attic

2023-02-04T03:29:15Z

Move to attic

← Older revision		Revision as of 03:29, 4 February 2023
Line 84:		Line 84:
	*[http://www.boost.org/doc/libs/1_39_0/libs/smart_ptr/shared_ptr.htm Full shared_ptr documentation at official Boost website]		*[http://www.boost.org/doc/libs/1_39_0/libs/smart_ptr/shared_ptr.htm Full shared_ptr documentation at official Boost website]
	*[http://www.boost.org/doc/libs/1_39_0/libs/ptr_container/doc/ptr_container.html Boost Pointer Container library]		*[http://www.boost.org/doc/libs/1_39_0/libs/ptr_container/doc/ptr_container.html Boost Pointer Container library]
			[[Category:Wiki Attic]]

PBS: Update C++11 notice

2023-02-04T03:23:53Z

Update C++11 notice

← Older revision		Revision as of 03:23, 4 February 2023
Line 1:		Line 1:
	= Notice: C++11 =		= Notice: C++11 =
	C++11 offers unique_ptr and shared_ptr, and should be used instead~~. Please check if we have switched to C++11 and if so, start using those. Search google for it, you'll find a lot of text about this great addition to the C++ standard~~.		C++11 offers <tt>unique_ptr</tt> and <tt>shared_ptr</tt>, and should be used instead.

	==Boost shared pointers==		==Boost shared pointers==

Johanengelen at 17:02, 13 November 2013

2013-11-13T17:02:47Z

← Older revision		Revision as of 17:02, 13 November 2013
Line 1:		Line 1:
			= Notice: C++11 =
			C++11 offers unique_ptr and shared_ptr, and should be used instead. Please check if we have switched to C++11 and if so, start using those. Search google for it, you'll find a lot of text about this great addition to the C++ standard.

			==Boost shared pointers==
	The Boost library is a set of peer-reviewed C++ libraries that play well with STL, and some of them are considered for inclusion in future versions of the C++ standard. They are generally regarded as well designed, useful, and powerful. They are also cross platform. All header-only Boost libraries can be used in Inkscape, since Boost is an accepted compile time dependency.		The Boost library is a set of peer-reviewed C++ libraries that play well with STL, and some of them are considered for inclusion in future versions of the C++ standard. They are generally regarded as well designed, useful, and powerful. They are also cross platform. All header-only Boost libraries can be used in Inkscape, since Boost is an accepted compile time dependency.

Tweenk: /* Shared pointers in member functions */

2011-07-25T18:52:21Z

Shared pointers in member functions

← Older revision		Revision as of 18:52, 25 July 2011
Line 62:		Line 62:
	==Shared pointers in member functions==		==Shared pointers in member functions==
	Sometimes a shared pointer to the current object is needed in its member function. Boost provides a mixin template class called <tt>enable_shared_from_this</tt>, which defines a no-argument member function called <tt>shared_from_this()</tt>. It returns a shared pointer to <tt>this</tt>. At least one instance of a shared pointer to this object must exist before the first use of this method; otherwise it has undefined results (usually crash). The best way to guarantee that this is condition met is to make the constructor protected and provide a factory method that returns a shared pointer to the newly created object.		Sometimes a shared pointer to the current object is needed in its member function. Boost provides a mixin template class called <tt>enable_shared_from_this</tt>, which defines a no-argument member function called <tt>shared_from_this()</tt>. It returns a shared pointer to <tt>this</tt>. At least one instance of a shared pointer to this object must exist before the first use of this method; otherwise it has undefined results (usually crash). The best way to guarantee that this is condition met is to make the constructor protected and provide a factory method that returns a shared pointer to the newly created object.
	class Foo : public enable_shared_from_this<Foo> {		class Foo : public boost::enable_shared_from_this<Foo> {
	public:		public:
	void someMethod() {		void someMethod() {

Tweenk: /* Rationale */

2009-07-26T00:48:53Z

Rationale

← Older revision		Revision as of 00:48, 26 July 2009
Line 7:		Line 7:
	==Rationale==		==Rationale==
	The memory management problem is how to guarantee that a program does not have any memory leaks. It can be solved with simple reference conuting if there are no cycles between objects. There are two approaches to solve it when :		The memory management problem is how to guarantee that a program does not have any memory leaks. It can be solved with simple reference conuting if there are no cycles between objects. There are two approaches to solve it when :
	# Garbage collection. Objects are created and left alone when no longer needed. When the memory is low, a background process kicks in and reclaims memory used by objects that can no longer be reached from the stack. This is the method used in most scripting languages, as well as Java and CLR. However, it has some drawbacks. Firstly, destructors can run at some indeterminate time after the object becomes unused, or never. This precludes using the RAII idiom. Secondly, ~~the~~ garbage ~~collector runs can take an unknown amount of time, which can make the application unresponsive~~. Thirdly, it requires some type information to be preserved at runtime, to determine where the garbage collector should look for object references.		# Garbage collection. Objects are created and left alone when no longer needed. When the memory is low, a background process kicks in and reclaims memory used by objects that can no longer be reached from the stack. This is the method used in most scripting languages, as well as Java and CLR. However, it has some drawbacks. Firstly, destructors can run at some indeterminate time after the object becomes unused, or never. This precludes using the RAII idiom. Secondly, there is some memory overhead associated with maintaining a garbage-collected heap. Thirdly, it requires some type information to be preserved at runtime, to determine where the garbage collector should look for object references - otherwise unrelated data can alias pointers, preventing some objects from being colleted.
	# Shared and weak pointers. This approach uses two types of object references to break the cycles. A shared pointer will keep the pointed object in memory ~~as long as it lives~~, while a weak pointer can be used to obtain a shared pointer to the same object, but will not prevent the object from destruction. This approach requires ~~a bit~~ more programming effort and adds some (negligible) overhead to each operation on the shared pointer, but makes object destruction predictable.		# Shared and weak pointers. This approach uses two types of object references to break the cycles. A shared pointer will keep the pointed object in memory, while a weak pointer can be used to obtain a shared pointer to the same object, but will not prevent the object from destruction. This approach requires more programming effort and adds some (negligible) overhead to each operation on the shared pointer, but makes object destruction predictable.

	The second method suits C++ ~~much~~ better than garbage collection. Firstly, there is generally little to no type information present at runtime to determine where to look for pointers to objects; Garbage collectors for C++ and C must assume that all data on the stack and all contents of the objects' memory are pointers to other objects. This can cause some unused memory to never be freed, because some integer in some object happens to have the same value as some other object's address. Secondly, since the C++ standard library and other libraries frequently use the RAII idiom, many C++ objects (like <tt>std::fstream</tt>) have non-trivial destructors. If those destructors are not run right after the object becomes unused, the program may hold on to resources it no longer uses, like file descriptors or database connections.		The second method suits C++ better than garbage collection. Firstly, there is generally little to no type information present at runtime to determine where to look for pointers to objects; Garbage collectors for C++ and C must assume that all data on the stack and all contents of the objects' memory are pointers to other objects (also known as conservative garbage collection). This can cause some unused memory to never be freed, because some integer in some object happens to have the same value as some other object's address. Secondly, since the C++ standard library and other libraries frequently use the RAII idiom, many C++ objects (like <tt>std::fstream</tt>) have non-trivial destructors. If those destructors are not run right after the object becomes unused, the program may hold on to resources it no longer uses, like file descriptors or database connections. Finally, using tricks like storing the color of a red-black tree node in the low bit of a pointer can in theory cause objects to be collected before they become unused, bu this can be mitigated with anchoring.

	==Shared pointers==		==Shared pointers==

Tweenk: Created page with 'The Boost library is a set of peer-reviewed C++ libraries that play well with STL, and some of them are considered for inclusion in future versions of the C++ standard. They are ...'

2009-07-20T22:28:22Z

Created page with 'The Boost library is a set of peer-reviewed C++ libraries that play well with STL, and some of them are considered for inclusion in future versions of the C++ standard. They are ...'

New page

The Boost library is a set of peer-reviewed C++ libraries that play well with STL, and some of them are considered for inclusion in future versions of the C++ standard. They are generally regarded as well designed, useful, and powerful. They are also cross platform. All header-only Boost libraries can be used in Inkscape, since Boost is an accepted compile time dependency.

This short tutorial will deal with the use of Boost shared pointers. They can be used to significantly reduce the amount of code needed for efficient memory management. Shared pointers with semantics identical to Boost ones are part of the C++ Library Technical Report 1, and will be included as part of the standard library in a future revision of C++.

If the ownership of objects is clear, investigate whether the simpler and lower overhead <tt>std::auto_ptr</tt> or <tt>boost::scoped_ptr</tt> can meet your needs. If you mainly need to use <tt>shared_ptr</tt> to put smart pointers in containers (since <tt>std::auto_ptr</tt> cannot be used in this way), investigate Boost pointer containers like <tt>boost::ptr_list</tt>.

==Rationale==
The memory management problem is how to guarantee that a program does not have any memory leaks. It can be solved with simple reference conuting if there are no cycles between objects. There are two approaches to solve it when :
# Garbage collection. Objects are created and left alone when no longer needed. When the memory is low, a background process kicks in and reclaims memory used by objects that can no longer be reached from the stack. This is the method used in most scripting languages, as well as Java and CLR. However, it has some drawbacks. Firstly, destructors can run at some indeterminate time after the object becomes unused, or never. This precludes using the RAII idiom. Secondly, the garbage collector runs can take an unknown amount of time, which can make the application unresponsive. Thirdly, it requires some type information to be preserved at runtime, to determine where the garbage collector should look for object references.
# Shared and weak pointers. This approach uses two types of object references to break the cycles. A shared pointer will keep the pointed object in memory as long as it lives, while a weak pointer can be used to obtain a shared pointer to the same object, but will not prevent the object from destruction. This approach requires a bit more programming effort and adds some (negligible) overhead to each operation on the shared pointer, but makes object destruction predictable.

The second method suits C++ much better than garbage collection. Firstly, there is generally little to no type information present at runtime to determine where to look for pointers to objects; Garbage collectors for C++ and C must assume that all data on the stack and all contents of the objects' memory are pointers to other objects. This can cause some unused memory to never be freed, because some integer in some object happens to have the same value as some other object's address. Secondly, since the C++ standard library and other libraries frequently use the RAII idiom, many C++ objects (like <tt>std::fstream</tt>) have non-trivial destructors. If those destructors are not run right after the object becomes unused, the program may hold on to resources it no longer uses, like file descriptors or database connections.

==Shared pointers==
Shared pointer is a smart pointer (a C++ object wih overloaded <tt>operator*()</tt> and <tt>operator->()</tt>) that keeps a pointer to an object and a pointer to a shared reference count. Every time a copy of the smart pointer is made using the copy constructor, the reference count is incremented. When a shared pointer is destroyed, the reference count for its object is decremented. Shared pointers constructed from raw pointers initially have a reference count of 1. When the reference count reaches 0, the pointed object is destroyed, and the memory it occupies is freed. You do not need to explicitly destroy objects: it will be done automatically when the last pointer's destructor runs.

===Usage===
When creating a new object with <tt>new</tt>, use it as a constructor argument of a <tt>boost::shared_ptr</tt>.
boost::shared_ptr<Foo> foo_ptr(new Foo());
You can reassign the pointer to a new object using the member function <tt>reset()</tt>. This will decrease the reference count of the old object, if any, and reinitialize the object with the argument and a reference count of 1.
foo_ptr.reset(new Foo());

Note however that you cannot obtain a shared pointer to an object from a raw pointer. This will cause a segmentation fault:
void some_function(Foo *f) {
boost::shared_ptr<Foo> fptr(f);
fptr->something();
}
...
Foo *foo = new Foo();
some_function(foo);
foo->something();
That's because the temporary <tt>fptr</tt> is initialized with a reference count of 1. After the function returns, the reference count is zero and the object is destroyed. <tt>foo->something()</tt> will then fail, because <tt>foo</tt> no longer points to a valid object.

An uninitialized shared pointer is ''empty''. This is equivalent to NULL for raw pointers. You can check for an empty shared pointer using this code:
if (foo) {
// foo points to an object
} else {
// foo is empty
}

A raw pointer can be retrieved using the <tt>get()</tt> method.
Foo *rawptr = fptr.get();

==Weak pointers==
Weak pointers can only be used to obtain a shared pointer to the same object, and check whether the object was already destroyed. They can be used to break circular references between objects. A weak pointer that points to an object that was already destroyed is called ''expired''. Empty weak pointers (that don't point to any object) are also expired.

Here is an example:
boost::shared_ptr<Foo> foo(new Foo());
boost::weak_ptr<Foo> weakfoo(foo);
...
boost::shared_ptr<Foo> fptr = weakfoo.lock();
if (fptr) {
// object still exists
} else {
// object already destroyed
}

Weak pointers cannot be dereferenced for thread safety reasons. If some other thread destroyed the object after you checked the weak pointer for expiry but before you used it, you would get a crash. Shared pointers can be obtained from weak pointers using use of two methods:
# <tt>boost::shared_ptr<Foo> fptr = weakfoo.lock();</tt> - fptr will be empty if <tt>weakfoo</tt> is expired. An exception will never be thrown.
# <tt>boost::shared_ptr<Foo> fptr(weakfoo);</tt> - the exception <tt>std::tr1::bad_weak_ptr</tt> will be thrown if <tt>weakfoo</tt> is expired.

==Shared pointers in member functions==
Sometimes a shared pointer to the current object is needed in its member function. Boost provides a mixin template class called <tt>enable_shared_from_this</tt>, which defines a no-argument member function called <tt>shared_from_this()</tt>. It returns a shared pointer to <tt>this</tt>. At least one instance of a shared pointer to this object must exist before the first use of this method; otherwise it has undefined results (usually crash). The best way to guarantee that this is condition met is to make the constructor protected and provide a factory method that returns a shared pointer to the newly created object.
class Foo : public enable_shared_from_this<Foo> {
public:
void someMethod() {
boost::shared_ptr<Foo> this_ = shared_from_this();
// use pointer...
}
...
static boost::shared_ptr<Foo> create() {
return boost::shared_ptr<Foo>(new Foo());
}
protected:
Foo() { ... }
...
};

==See also==
*[http://www.boost.org/doc/libs/1_39_0/libs/smart_ptr/shared_ptr.htm Full shared_ptr documentation at official Boost website]
*[http://www.boost.org/doc/libs/1_39_0/libs/ptr_container/doc/ptr_container.html Boost Pointer Container library]