00001 00002 00003 \page Reference_counting__ Reference counting 00004 00005 Because objects management in the C++ programming language defaults to \ 00006 \e value semantics, we have to take explicit actions to avoid copying 00007 large objects -- the time spent in copying large objects may be shown to be 00008 non negligible under usual circumstances. A popular way to solve that memory 00009 management problem is to use reference counting coupled with a copy-on-write 00010 strategy. 00011 00012 Concretely, each object (of type \c VectDse, \ \c MatrDse, 00013 \c MatrStr, \ \c MatrSps, \c UPolDse or 00014 \c MPol, used as template-arguments for our containers) is attached 00015 with a counter whose purpose is to keep track of the number of references to 00016 its associated object. An assignment to a new object will increment the 00017 counter and copy the actual data's address. A modification of the shared 00018 object will induce a copy of the data leading to a new shared object with 00019 counter 0. The object's destructor either decrements the counter (if it is 00020 positive) or else effectively destroys the data, thereby freeing its storage. 00021 00022 The overall scheme is implemented by the class \tmtexttt{shared\_object<R>}. 00023 Therefore, returning such objects by value in a function as in 00024 00025 00026 \code 00027 VectDse<C> F(...) { VectDse<C> W= ...; return W; } 00028 \endcode 00029 00030 00031 does not induce a performance penalty. Indeed a copy and destruction of 00032 \c W will in this case just increment or decrement a counter. 00033 00034
|