105 lines
4.5 KiB
ReStructuredText
105 lines
4.5 KiB
ReStructuredText
++++++++++++++++++++++++++++++++++
|
|
|Boost| Pointer Container Library
|
|
++++++++++++++++++++++++++++++++++
|
|
|
|
.. |Boost| image:: boost.png
|
|
|
|
|
|
FAQ
|
|
===
|
|
|
|
.. contents:: :local:
|
|
|
|
Calling ``assign()`` is very costly and I do not really need to store cloned objects; I merely need to overwrite the existing ones; what do I do?
|
|
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
|
|
|
Call ``std::copy( first, last, c.begin() );``.
|
|
|
|
Which mutating algorithms are safe to use with pointers?
|
|
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
|
|
|
Any mutating algorithm that moves elements around by swapping them. An
|
|
important example is ``std::sort()``; examples of unsafe algorithms are
|
|
``std::unique()`` and ``std::remove()``.
|
|
|
|
.. That is why these algorithms are
|
|
provided as member functions.
|
|
|
|
Why does ``ptr_map<T>::insert()/replace()`` take two arguments (the key and the pointer) instead of one ``std::pair``? And why is the key passed by non-const reference?
|
|
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
|
|
|
This is the only way the function can be implemented in an exception-safe
|
|
manner; since the copy-constructor of the key might throw, and since
|
|
function arguments are not guaranteed to be evaluated from left to right,
|
|
we need to ensure that evaluating the first argument does not throw.
|
|
Passing the key as a reference achieves just that.
|
|
|
|
When instantiating a pointer container with a type ``T``, is ``T`` then allowed to be incomplete at that point?
|
|
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
|
|
|
No. This is a distinct property of ``shared_ptr`` which implies some overhead.
|
|
|
|
However, one can leave ``T`` incomplete in the header file::
|
|
|
|
// foo.hpp
|
|
class Foo { ... };
|
|
new_clone( const Foo& ) { ... }
|
|
delete_clone( const Foo* ) { ... }
|
|
|
|
// x.hpp
|
|
class Foo; // Foo is incomplete here
|
|
class X { ptr_deque<Foo> container; ... }
|
|
|
|
// x.cpp
|
|
#include <x.hpp>
|
|
#include <foo.hpp> // now Foo is not incomplete anymore
|
|
...
|
|
|
|
|
|
|
|
Why do iterator-range inserts give the strong exception-safety guarantee?
|
|
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
|
|
|
Is this not very inefficient? It is because it is actually affordable to
|
|
do so; the overhead is one heap-allocation which is relatively small
|
|
compared to cloning N objects.
|
|
|
|
What is the _`polymorphic class problem`?
|
|
+++++++++++++++++++++++++++++++++++++++++
|
|
|
|
The problem refers to the relatively troublesome way C++ supports Object
|
|
Oriented programming in connection with containers of pointers to
|
|
polymorphic objects. In a language without garbage collection, you end up
|
|
using either a container of smart pointers or a container that takes
|
|
ownership of the pointers. The hard part is to find a safe, fast and
|
|
elegant solution.
|
|
|
|
Are the pointer containers faster and do they have a better memory footprint than a container of smart pointers?
|
|
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
|
|
|
The short answer is yes: they are faster and they do use less memory; in
|
|
fact, they are the only way to obtain the zero-overhead hallmark of C++.
|
|
Smart pointers usually have one word or more of memory overhead per
|
|
pointer because a reference count must be maintained. And since the
|
|
reference count must be maintained, there is also a runtime-overhead. If
|
|
your objects are big, then the memory overhead is often negligible, but if
|
|
you have many small objects, it is not. Further reading can be found in
|
|
these references: `[11] <ptr_container.html#references>`_ and `[12] <ptr_container.html#references>`_.
|
|
|
|
When the stored pointers cannot be ``0``, how do I allow this "empty" behavior anyway?
|
|
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
|
|
|
Storing a null-pointer among a list of pointers does not fit well into the Object Oriented paradigm.
|
|
The most elegant design is to use the Null-Object Pattern where one basically makes a concrete
|
|
class with dummy implementations of the virtual functions. See `[13] <ptr_container.html#references>`_ for details.
|
|
|
|
.. raw:: html
|
|
|
|
<hr>
|
|
|
|
:Copyright: Thorsten Ottosen 2004-2006. Use, modification and distribution is subject to the Boost Software License, Version 1.0 (see LICENSE_1_0.txt__).
|
|
|
|
__ http://www.boost.org/LICENSE_1_0.txt
|
|
|
|
|