Thank you David for the hint!
I re read the "An in-depth explanation" part of
http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap-idiom/3279550#3279550,
it's great ! I understood when and above all how the memory is cleaned.
About your multidimalgorithm, what would be the problem if it'd be changed
like this ? (to sum up: passing parameter by value to optimize)
/include/mdds/flat_segment_tree.hpp
flat_segment_tree<key_type, value_type>&
operator=(flat_segment_tree<key_type, value_type> other);
/include/mdds/flat_segment_tree_def.inl
template<typename _Key, typename _Value>
flat_segment_tree<_Key, _Value>&
flat_segment_tree<_Key, _Value>::operator=(flat_segment_tree<_Key,
_Value>
other)
{
swap(copy);
return *this;
}
this part of
http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap-idiom/3279550#3279550
made me think about this:
Observe that upon entering the function that all the new data is already
allocated, copied, and ready to be used. This is what gives us a strong
exception guarantee for free: we won't even enter the function if
construction of the copy fails, and it's therefore not possible to alter the
state of *this. (What we did manually before for a strong exception
guarantee, the compiler is doing for us now; how kind.)
Is this design pattern without flaw (does it exist ? :-)) and be applied in
every case in LO code ?
Thank you too Stephan about the refs. First I must finish Stroustrup's book
and the way is long because I never really coded in C++ just some Java (when
it was in 1.3) and few C and VB.
Julien
--
View this message in context:
http://nabble.documentfoundation.org/PATCH-cleaning-before-assignment-lotuswordpro-source-filter-xfilter-xfparastyle-cxx-tp3995480p3996515.html
Sent from the Dev mailing list archive at Nabble.com.
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
