[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfe-dev
Subject:    [cfe-dev] Fwd: Move constructor forces copy assignment to be implicitly defaulted?
From:       Suman Kar <skarpio () gmail ! com>
Date:       2012-05-29 16:47:25
Message-ID: CANtNSk+Y5mOYwoi04c7xqWmUTkKB+2D4RqG84fRfoOkSSBzafA () mail ! gmail ! com
[Download RAW message or body]

On Tue, May 29, 2012 at 3:51 AM, Howard Hinnant <hhinnant@apple.com> wrote:
> On May 28, 2012, at 4:26 PM, Suman Kar wrote:
> 
> > A quick question:
> > 
> > struct A {};
> > 
> > struct B : A { ~B() {} };
> > 
> > A makeA() {
> > A a;
> > return a;
> > }
> > 
> > B makeB() {
> > B b;
> > return b;
> > }
> > 
> > int main() {
> > A a = makeA();
> > B b = makeB();
> > }
> > 
> > Is it correct to assume that A will be moved and B will not?
> 
> Yes.
> 
> > Should a
> > diagnostic be required for the call to makeB?
> 
> No.  B should be allowed to to suppress an implicit move constructor.  The implicit \
> version might do the wrong thing. 
> But you can create your own compile-time diagnostic.
> 

Right. My point was that the behavior changes subtly across a
hierarchy. This can be a spot of bother when designing. I understand
the reason -- since the user *defined* a destructor somewhere down the
hierarchy, the compiler (correctly) stays away from (using a crystal
ball and) moving stuff.

There is also this tendency among beginning programmers to define an
empty destructor (for no good reason perhaps and I've seen quite a few
such cases with seasoned ones too). Suddenly, a no-op definition
starts costing more!

Let me summarize my understanding (along with what you've already
written) w.r.t move members:

[1] While both copy and move members can be implicitly
defaulted/deleted only move members can be suppressed.
[2] A move member can never be implicitly defined to be deleted
because of the presence of a copy member or a destructor.

Finally, there's this bit about 12.8/9 that I need help with:

   When the move constructor is not implicitly declared or explicitly
   supplied, expressions that otherwise would have invoked the move
   constructor may instead invoke a copy constructor.

This, I believe, keeps the compiler happy about compiling the example
I posted? Also, is

   'When the move constructor is not implicitly declared or explicitly
   supplied'

standardese for suppressed/inhibited/deprecated?

Is it correct to consider the case where move members are deprecated
as C++98/03 fallback mode?

Regards,
Suman

_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


[prev in list] [next in list] [prev in thread] [next in thread]