lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Move decays to copy


From: Vadim Zeitlin
Subject: Re: [lmi] Move decays to copy
Date: Wed, 13 Jul 2022 01:19:29 +0200

On Tue, 12 Jul 2022 21:57:04 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> [...this crossed in the mail with your reply, but let's see if we agree...]

 I think so, but I still want to clarify something to be absolutely sure:

GC> Class gpt_state declares no "move" special members. That doesn't
GC> mean it's an error to ask to move gpt_server's gpt_state member;

 But how exactly do you ask to move it? You never actually do this. The
move ctor is used if it's selected by the overload resolution. If it's not
available, it's not selected and hence not used.

GC> it just means that such a request will be fulfilled by copying
GC> that member.

 Yes, because the overload resolution will find the copy ctor instead:
"T const&" matches "T&&" too, even if "T&&" matches better.

GC> There might be good reason to implement move semantics for class
GC> gpt_state, for the sake of efficiency, but that's not necessary
GC> for correctness.

 Yes.
VZ

Attachment: pgpd2kfTfMKnF.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]