Re: [boost] [xint] Performance of fixed-size large integers

Subject: Re: [boost] [xint] Performance of fixed-size large integers
From: Ivan Le Lann (ivan.lelann_at_[hidden])
Date: 2011-03-05 19:29:47

Le samedi 05 mars 2011 à 12:07 +0000, Christopher Jefferson a écrit :
> On 5 Mar 2011, at 12:04, Ivan Le Lann wrote:
> > 
> > The opposite view also stands: Move will benefit to most C++
> > classes/functions while only those who have designed their classes to
> > use COW can afford not to use Move. Designing a COW class is more
> > complex than a Move enabled one.
> > 
> > My KISS understanding of move is that it's telling me: use functional
> > programming style, so that you don't need std::move.
> > Of course, this is not always possible, but I think that this limits the
> > scope of your (valid) point.
> 
> You seem to be saying that COW makes things harder on the implementor, but easier on the user (as they do not have to use either std::move, or carefully designed coding methods)
> 

I only considered coding style here and from that point of view, yes,
though I would not have said easier but more lenient.
Unless using auto&& which can break your code just like auto_ptr did,
just naming a variable prevents move. Many people use named variables
for documentation and code readability. Thus I dare to say that move is
"coding style touchy".

Going further, the user also has to consider delivered service in terms
of performance and thread safety. It seems there is a concensus against
COW. I have no idea on this. I trust benchmarks and smart guys, and my
intuition that simpler things are better.
As I said, I consider move simpler.

Having said that, we (and me first) should stop opposing COW and Move.
Move is here and works at a different level. It even minimizes COW
flaws. So it's not about "COW or Move?". It's about "To copy or not to
copy?". I guess some people here want a C++ where you have to call
std::copy to invoke a copy constructor. :-)

Ivan