|
Boost : |
From: Vaclav Vesely (vaclav.vesely_at_[hidden])
Date: 2006-03-20 17:42:03
Howard Hinnant wrote:
>> Default implementation for move is copy assignment. But for each
>> type should be safe alternative implementation by swap. Maybe the
>> swap could be good default implementation for types without trivial
>> copy constructor. I can't imagine an example of a type with non-
>> trivial constructor, where copy implementation would be more
>> effective.
>
> One example is pair<string, int>. :-( Admittedly this is because
> pair doesn't have a swap
...
My current move implementation for pairs uses explicit move functions
for pairs. But wouldn't be better to specialize std::swap for pairs in
Boost.Utility until the new STL would contain it? The same for tuples. I
can write special move functions for them. But adding swap for tuples
and then reuse it for moving seems to be more useful.
>> Default implementation is copy construct. For classes with default
>> constructor can be move effective to default construct and than
>> swap.
...
> You've got a convenience - performance tradeoff going here. What you
> have seems most convenient. However the memcpy/memset algorithm,
> especially if it doesn't actually call memcpy and memset, ...
How can I use memecpy/memset algorithm without call them?
> ... is going to
> be faster than default construct then swap for some types. Perhaps
> that just adds up to a documentation issue?
... [an example with vector]
> 3 reads, 6 writes.
> Versus:
> 9 reads, 12 writes, which looks over 2x slower.
For me this is not crucial difference. What I'm trying to optimize is
copying of the contents of containers which can be arbitrary large.
However adding support for memcpy is easy so it can be there ready for
use. But I'm not sure with usage. When I have a class which can be moved
by memcpy, is it correct to set has_trivial_move_assign/constructor? Or
has_trivial traits should mean, that the corresponding member functions
are automatically generated by compiler?
Regards,
Vaclav
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk