Boost logo

Boost :

Subject: Re: [boost] [proposal] raw move (was: [interest] underlying type library)
From: Christopher Jefferson (chris_at_[hidden])
Date: 2011-08-23 11:17:52


On 23 Aug 2011, at 16:08, Julian Gonggrijp wrote:

> Christopher Jefferson wrote:
>
>> Simple reasons can be misleading. Are you sure the gain is substantial enough?
>
> No, to be honest I'm not sure. I'll write a benchmark.
>
> However, I don't really see why you would want to include operations
> in your code of which you know beforehand that they schould be
> optimized away by the compiler. Part of the reason to adopt move
> assigments was exactly that: we don't want to insert operations in our
> code of which we know beforehand we don't want them executed.

The reason for move assignment is that no compiler can (and I'm unsure any compiler could, within reason) optimise a std::vector copy to a std::vector move. Therefore move construction was introduced to the standard.

When moving was originally discussed, things like 'destructive' and 'raw' moves were discussed, but it was decided in the end they were too dangerous, without proving substantial benefits. For example, you can rearrange a list of std::vectors with memcpy, but if you get half way through and an exception is thrown and you end up with the same vector left in two places in memory, horrible things will happen as they will refer to the same memory block.

I myself was seduced by the call of these kinds of rawer moves, but having now implemented chucks of a standard library and quite a few bits of my own code using std::move, I believe it is the right trade-off. To convince people to do something else will require impressive benchmarks.

>
>
>> As well as discussing, has anyone else come up with good benchmarks (I couldn't find any in the thread you referred to).
>
> Not that I know of.
>
>
> -Julian
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


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