Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #13792 > unrolled thread

member function swap vs std::move

Back to article view | Back to comp.lang.c++

Contents

  member function swap vs std::move m0shbear <andrey.vul@gmail.com> - 2012-02-05 14:41 -0800
    Re: member function swap vs std::move 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-05 17:40 -0800
      Re: member function swap vs std::move Fabrizio J Bonsignore <syntotic@gmail.com> - 2012-02-05 18:17 -0800
        Re: member function swap vs std::move Fabrizio J Bonsignore <syntotic@gmail.com> - 2012-02-05 18:30 -0800
        Re: member function swap vs std::move 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-05 19:33 -0800
      Re: member function swap vs std::move 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-07 06:02 -0800

#13792 — member function swap vs std::move

Suppose I have a container type C<T>, which implements
MoveConstructable, MoveAssignable, and member function swap(C<T>&).

In which case is it more elegant to use
C<T> c1;
// fill c1 with data
C<T> c2 = std::move(c1);

over

C<T> c1;
// fill c1 with data
C<T> c2;
c2.swap(c1);

?

Granted, the .swap technique was a hack for moving containers in pre-C+
+11 classes, but now that C++11 is out, does it have any merit for new
classes?

[toc] | [next] | [standalone]

#13794

If the object in any class was stored as one or more  continuos blocks of memory
in the compiled or interpreted executables, then the action of swap of two objects in the same class can be faster than the C++ way. 

The multi-class inheritance allowed in C++ adds more overheads in any
copy contructor or assignment operations. 

In C the assignment operation allowed in any parensis does not add too much
overhead, since C types are supposed to be register holdables in HW.

But the same teasing trick in C++ is just slowing down some basic operations 
in objects of muti-level multi-class-inherant classes. 

Thus, it requires more skills to write and maintain C++ codes.

[toc] | [prev] | [next] | [standalone]

#13796

What about the memory-runtime tradeoff? Can you be more specific as to
where you spend more runtime to save more memory and viceversa? Swap
should always be more memory intensive; move can be done purely
runtime with a single intermediate hold variable, independently of how
many castings/polymorphisms/new-copy constructors you might have to
call. (Particularly with swap you would be invoking copy constructors
a gallore, so they may be factorized out of the comparison function,
but it would depend on your pointer-auto object regime). What
framework did you say you are using this in?

Danilo J Bonsignore

[toc] | [prev] | [next] | [standalone]

#13797

(Oh, if you just move:: and there IS a guaranteed zero object in the
array, you can always use the zero object already there as swap memory
and regenerate it lastly with a copy assignment-new object. Keeping an
index/pointer would be more efficient than holding a whole auto
object. You can also reserve index zero for Zero object and use it as
swap memory/working memory already there, cf, the reserved variables
in WM$ structures).

Danilo J Bonsignore

[toc] | [prev] | [next] | [standalone]

#13799

在 2012年2月6日星期一UTC+8上午10时17分02秒，Fabrizio J Bonsignore写道：
> What about the memory-runtime tradeoff? Can you be more specific as to
> where you spend more runtime to save more memory and viceversa? Swap
> should always be more memory intensive; move can be done purely
> runtime with a single intermediate hold variable, independently of how
> many castings/polymorphisms/new-copy constructors you might have to
> call. (Particularly with swap you would be invoking copy constructors
> a gallore, so they may be factorized out of the comparison function,
> but it would depend on your pointer-auto object regime). What
> framework did you say you are using this in?
> 
> Danilo J Bonsignore

Condsider a class inherited in 6 levels from the root and at each level of 
2 to 6 mutilevel inheritances of classes, then the growth of an expoential rate of memory used by an object for its properties and methods from all super classes in the class level is unavoiadable. Thus,  for an object in a class that has to support all its upper classes functionality eat the heap like a hog
very often.

This helps the DRAM industry a lot, but it does not help in training professional programmers to produce better SW. Unless the programmers will 
gain profits from the DRAM sellers, I can't agree with those teasing tricks
as a SW programmer. 

[toc] | [prev] | [next] | [standalone]

#13816

在 2012年2月7日星期二UTC+8下午2时19分55秒，Juha Nieminen写道：
> 88888 Dihedral <dihedral88888@googlemail.com> wrote:
> > If the object in any class was stored as one or more  continuos blocks of memory
> > in the compiled or interpreted executables, then the action of swap of two objects in the same class can be faster than the C++ way. 
> 
>   Your text is quite incoherent.
> 
>   I believe that what you are *trying* to say is that if all objects were
> handled by reference (as they are eg. in Java or Objective-C) rather than
> by value (as in C++), then swapping two objects would be way faster.
> 
>   Except that in this case you wouldn't be swapping the contents of the
> objects, but just the two references. Any third reference would not see
> the swap.

I agree with you. The refefrence scheme in swapping is faster.    

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web