]>
Commit | Line | Data |
---|---|---|
7c673cae FG |
1 | ++++++++++++++++++++++++++++++++++ |
2 | |Boost| Pointer Container Library | |
3 | ++++++++++++++++++++++++++++++++++ | |
4 | ||
5 | .. |Boost| image:: boost.png | |
6 | ||
7 | ||
8 | FAQ | |
9 | === | |
10 | ||
11 | .. contents:: :local: | |
12 | ||
13 | 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? | |
14 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | |
15 | ||
16 | Call ``std::copy( first, last, c.begin() );``. | |
17 | ||
18 | Which mutating algorithms are safe to use with pointers? | |
19 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | |
20 | ||
21 | Any mutating algorithm that moves elements around by swapping them. An | |
22 | important example is ``std::sort()``; examples of unsafe algorithms are | |
23 | ``std::unique()`` and ``std::remove()``. | |
24 | ||
25 | .. That is why these algorithms are | |
26 | provided as member functions. | |
27 | ||
28 | 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? | |
29 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | |
30 | ||
31 | This is the only way the function can be implemented in an exception-safe | |
32 | manner; since the copy-constructor of the key might throw, and since | |
33 | function arguments are not guaranteed to be evaluated from left to right, | |
34 | we need to ensure that evaluating the first argument does not throw. | |
35 | Passing the key as a reference achieves just that. | |
36 | ||
37 | When instantiating a pointer container with a type ``T``, is ``T`` then allowed to be incomplete at that point? | |
38 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | |
39 | ||
40 | No. This is a distinct property of ``shared_ptr`` which implies some overhead. | |
41 | ||
42 | However, one can leave ``T`` incomplete in the header file:: | |
43 | ||
44 | // foo.hpp | |
45 | class Foo { ... }; | |
46 | new_clone( const Foo& ) { ... } | |
47 | delete_clone( const Foo* ) { ... } | |
48 | ||
49 | // x.hpp | |
50 | class Foo; // Foo is incomplete here | |
51 | class X { ptr_deque<Foo> container; ... } | |
52 | ||
53 | // x.cpp | |
54 | #include <x.hpp> | |
55 | #include <foo.hpp> // now Foo is not incomplete anymore | |
56 | ... | |
57 | ||
58 | ||
59 | ||
60 | Why do iterator-range inserts give the strong exception-safety guarantee? | |
61 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | |
62 | ||
63 | Is this not very inefficient? It is because it is actually affordable to | |
64 | do so; the overhead is one heap-allocation which is relatively small | |
65 | compared to cloning N objects. | |
66 | ||
67 | What is the _`polymorphic class problem`? | |
68 | +++++++++++++++++++++++++++++++++++++++++ | |
69 | ||
70 | The problem refers to the relatively troublesome way C++ supports Object | |
71 | Oriented programming in connection with containers of pointers to | |
72 | polymorphic objects. In a language without garbage collection, you end up | |
73 | using either a container of smart pointers or a container that takes | |
74 | ownership of the pointers. The hard part is to find a safe, fast and | |
75 | elegant solution. | |
76 | ||
77 | Are the pointer containers faster and do they have a better memory footprint than a container of smart pointers? | |
78 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | |
79 | ||
80 | The short answer is yes: they are faster and they do use less memory; in | |
81 | fact, they are the only way to obtain the zero-overhead hallmark of C++. | |
82 | Smart pointers usually have one word or more of memory overhead per | |
83 | pointer because a reference count must be maintained. And since the | |
84 | reference count must be maintained, there is also a runtime-overhead. If | |
85 | your objects are big, then the memory overhead is often negligible, but if | |
86 | you have many small objects, it is not. Further reading can be found in | |
87 | these references: `[11] <ptr_container.html#references>`_ and `[12] <ptr_container.html#references>`_. | |
88 | ||
89 | When the stored pointers cannot be ``0``, how do I allow this "empty" behavior anyway? | |
90 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | |
91 | ||
92 | Storing a null-pointer among a list of pointers does not fit well into the Object Oriented paradigm. | |
93 | The most elegant design is to use the Null-Object Pattern where one basically makes a concrete | |
94 | class with dummy implementations of the virtual functions. See `[13] <ptr_container.html#references>`_ for details. | |
95 | ||
96 | .. raw:: html | |
97 | ||
98 | <hr> | |
99 | ||
100 | :Copyright: Thorsten Ottosen 2004-2006. Use, modification and distribution is subject to the Boost Software License, Version 1.0 (see LICENSE_1_0.txt__). | |
101 | ||
102 | __ http://www.boost.org/LICENSE_1_0.txt | |
103 | ||
104 |