[PATCH] cleaning before = assignment lotuswordpro/source/filter/xfilter/xfparastyle.cxx

[David Tardon]

Hi,

On Thu, Jul 19, 2012 at 02:03:39PM -0700, julien2412 wrote:
> 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;
>  	}

It is equivalent to the current code. Just most C++ programmers
(including me :-) are accustomed to the "fact" that operator= takes its
argument by const reference...

> 
> 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.)

Yeah, it is even a line shorter :-) But whether a function call is (not)
eliminated in the case an exception is thrown would be the last of my
worries (it is _exceptional_ situation, after all... And the gain of
avoiding the call would be more than offset by the cost of the exception
processing mechanism.)

> 
> Is this design pattern without flaw (does it exist ? :-)) and be applied in
> every case in LO code ?

Well, we do not typically care so much about exceptions in LO (heck,
there is code--and probably a lot of it--that does not even have weak
exception guarantee). So it is probably not so useful to start adapting
the assignment operators in our codebase en masse.

D.