]>
Commit | Line | Data |
---|---|---|
15b6757b | 1 | ///////////////////////////////////////////////////////////////////////////// |
72844950 | 2 | // Name: refcount.h |
15b6757b FM |
3 | // Purpose: topic overview |
4 | // Author: wxWidgets team | |
5 | // RCS-ID: $Id$ | |
6 | // Licence: wxWindows license | |
7 | ///////////////////////////////////////////////////////////////////////////// | |
8 | ||
880efa2a | 9 | /** |
36c9828f | 10 | |
72844950 | 11 | @page overview_refcount Reference Counting |
36c9828f | 12 | |
72844950 BP |
13 | @li @ref overview_refcount_ignore |
14 | @li @ref overview_refcount_equality | |
15 | @li @ref overview_refcount_destruct | |
16 | @li @ref overview_refcount_list | |
17 | @li @ref overview_refcount_object | |
36c9828f FM |
18 | |
19 | ||
72844950 | 20 | <hr> |
36c9828f | 21 | |
36c9828f | 22 | |
72844950 | 23 | @section overview_refcount_ignore Why You Shouldn't Care About It |
36c9828f | 24 | |
72844950 BP |
25 | Many wxWidgets objects use a technique known as <em>reference counting</em>, |
26 | also known as <em>copy on write</em> (COW). This means that when an object is | |
27 | assigned to another, no copying really takes place. Only the reference count on | |
28 | the shared object data is incremented and both objects share the same data (a | |
29 | very fast operation). | |
36c9828f | 30 | |
72844950 BP |
31 | But as soon as one of the two (or more) objects is modified, the data has to be |
32 | copied because the changes to one of the objects shouldn't be seen in the | |
33 | others. As data copying only happens when the object is written to, this is | |
34 | known as COW. | |
36c9828f | 35 | |
72844950 BP |
36 | What is important to understand is that all this happens absolutely |
37 | transparently to the class users and that whether an object is shared or not is | |
38 | not seen from the outside of the class - in any case, the result of any | |
39 | operation on it is the same. | |
36c9828f | 40 | |
36c9828f | 41 | |
72844950 | 42 | @section overview_refcount_equality Object Comparison |
36c9828f | 43 | |
3ed3a1c8 BP |
44 | The == and != operators of @ref overview_refcount_list "the reference counted classes" |
45 | always do a <em>deep comparison</em>. This means that the equality operator | |
46 | will return @true if two objects are identical and not only if they share the | |
47 | same data. | |
36c9828f | 48 | |
72844950 BP |
49 | Note that wxWidgets follows the <em>STL philosophy</em>: when a comparison |
50 | operator can not be implemented efficiently (like for e.g. wxImage's == | |
51 | operator which would need to compare the entire image's data, pixel-by-pixel), | |
52 | it's not implemented at all. That's why not all reference counted classes | |
53 | provide comparison operators. | |
36c9828f | 54 | |
72844950 | 55 | Also note that if you only need to do a @c shallow comparison between two |
7442b5ee | 56 | wxObject derived classes, you should not use the == and != operators but |
f0a9a84c | 57 | rather the wxObject::IsSameAs() function. |
36c9828f | 58 | |
36c9828f | 59 | |
72844950 | 60 | @section overview_refcount_destruct Object Destruction |
36c9828f | 61 | |
72844950 BP |
62 | When a COW object destructor is called, it may not delete the data: if it's |
63 | shared, the destructor will just decrement the shared data's reference count | |
64 | without destroying it. Only when the destructor of the last object owning the | |
65 | data is called, the data is really destroyed. Just like all other COW-things, | |
66 | this happens transparently to the class users so that you shouldn't care about | |
67 | it. | |
36c9828f | 68 | |
36c9828f | 69 | |
72844950 | 70 | @section overview_refcount_list List of Reference Counted Classes |
36c9828f | 71 | |
72844950 BP |
72 | The following classes in wxWidgets have efficient (i.e. fast) assignment |
73 | operators and copy constructors since they are reference-counted: | |
36c9828f | 74 | |
7442b5ee BP |
75 | @li wxAcceleratorTable |
76 | @li wxAnimation | |
77 | @li wxBitmap | |
78 | @li wxBrush | |
79 | @li wxCursor | |
80 | @li wxFont | |
81 | @li wxIcon | |
82 | @li wxImage | |
83 | @li wxMetafile | |
84 | @li wxPalette | |
85 | @li wxPen | |
86 | @li wxRegion | |
87 | @li wxString | |
88 | @li wxVariant | |
89 | @li wxVariantData | |
36c9828f | 90 | |
72844950 BP |
91 | Note that the list above reports the objects which are reference counted in all |
92 | ports of wxWidgets; some ports may use this technique also for other classes. | |
36c9828f | 93 | |
3ed3a1c8 BP |
94 | All the objects implement a function @b IsOk() to test if they are referencing valid |
95 | data; when the objects are in uninitialized state, you can only use the @b IsOk() getter; | |
f0a9a84c FM |
96 | trying to call any other getter, e.g. wxBrush::GetStyle() on the ::wxNullBrush object, |
97 | will result in an assert failure in debug builds. | |
98 | ||
36c9828f | 99 | |
72844950 | 100 | @section overview_refcount_object Making Your Own Reference Counted Class |
36c9828f | 101 | |
7442b5ee BP |
102 | Reference counting can be implemented easily using wxObject and wxObjectRefData |
103 | classes. Alternatively, you can also use the wxObjectDataPtr<T> template. | |
36c9828f | 104 | |
7442b5ee | 105 | First, derive a new class from wxObjectRefData and put there the |
72844950 | 106 | memory-consuming data. |
36c9828f | 107 | |
7442b5ee | 108 | Then derive a new class from wxObject and implement there the public interface |
72844950 | 109 | which will be seen by the user of your class. You'll probably want to add a |
7442b5ee | 110 | function to your class which does the cast from wxObjectRefData to your |
72844950 | 111 | class-specific shared data. For example: |
36c9828f | 112 | |
72844950 BP |
113 | @code |
114 | MyClassRefData* GetData() const | |
115 | { | |
116 | return wx_static_cast(MyClassRefData*, m_refData); | |
117 | } | |
118 | @endcode | |
36c9828f | 119 | |
72844950 BP |
120 | In fact, any time you need to read the data from your wxObject-derived class, |
121 | you will need to call this function. | |
36c9828f | 122 | |
72844950 | 123 | @note Any time you need to actually modify the data placed inside your wxObject |
3ed3a1c8 | 124 | derived class, you must first call the wxObject::UnShare() function to ensure |
72844950 BP |
125 | that the modifications won't affect other instances which are eventually |
126 | sharing your object's data. | |
36c9828f | 127 | |
72844950 | 128 | */ |
36c9828f | 129 |