Boost logo

Boost :

Subject: Re: [boost] [xint] Performance of fixed-size large integers
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-03-04 16:58:36


> From: Mathias Gaunard <mathias.gaunard_at_[hidden]>
> To: boost_at_[hidden]
> Sent: Fri, March 4, 2011 8:36:05 PM
> Subject: Re: [boost] [xint] Performance of fixed-size large integers
>
> On 04/03/2011 19:01, Christopher Jefferson wrote:
>
> > There are still cases where COW can beat move semantics. For example,
> > I have need of the same integer in multiple places.
>
> Then you should have all those places refer to the same integer, not make all
> those places hold a copy of it.
>

We can all argue that move is sometimes better then COW and we can argue
that COW is in past as move semantics is the future.

I just want to remind few things:

1. Most of compiles that use Boost today and will use it for many years
   do not support rvalue reference and real move semantics.

2. As long as it is not in the main stream (and it is not) most of qualified
   programmers are not going to use std::move as it is not portable and makes
   the software to depend on very recent compilers versions and on
   the standard that was not even released yet(!)

3. COW is widely used technique. What is very important, is that it is in use
   in common practice in many libraries and places. It is well understood by
   good C++ programmers.

Yes, it is probably good to have support of move semantics but do not
expect it to me the mainstream in near future.

So you need to ask yourself:

1. Who benefits from COW semantics?
2. Who benefits from move semantics?

I personally think that COW approach would be very useful for most
of users while move is "nice-to-have".

And to clarify it: I'm talking about real world and real programmers
who deal and maintain real code.

I think that COW approach is the correct approach at this point
in the real world applications.

My $0.02

Artyom

      


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk