[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 13:29:23 +0200 |
On Wed, 13 Jul 2022 00:47:17 +0000 Greg Chicares <gchicares@sbcglobal.net>
wrote:
GC> On 7/12/22 23:19, Vadim Zeitlin wrote:
GC> > On Tue, 12 Jul 2022 21:57:04 +0000 Greg Chicares
<gchicares@sbcglobal.net> wrote:
GC> >
GC> > GC> [...this crossed in the mail with your reply, but let's see if we
agree...]
GC> >
GC> > I think so, but I still want to clarify something to be absolutely sure:
GC> >
GC> > GC> Class gpt_state declares no "move" special members. That doesn't
GC> > GC> mean it's an error to ask to move gpt_server's gpt_state member;
GC> >
GC> > But how exactly do you ask to move it? You never actually do this. The
GC> > move ctor is used if it's selected by the overload resolution. If it's not
GC> > available, it's not selected and hence not used.
GC>
GC> I ask to move the gpt_state member by declaring a defaulted move
GC> ctor for gpt_server, and by writing code for which the language
GC> selects the move ctor as a better match than the copy ctor.
But my point is that there is no special syntax to ask for the object to
be moved in C++. All you can do is to write class_name(reference_to_object)
but then you still let the compiler select the appropriate ctor to use.
There is no way to force the move here (although you can check if move ctor
is available and give a compile-time error if it isn't).
FWIW other languages (Rust, not to name it) do have explicit "move"
operations, but C++ doesn't, confusingly named std::move() notwithstanding.
GC> In the "Is this class moveable or not?" subthread, I present
GC> my understanding thus:
GC>
GC> for each data member M
GC> if M is moveable, move it
GC> else copy it
GC>
GC> and so I believe that I'm asking the language to move each
GC> subobject, if possible.
No, sorry, I don't think this is correct. Either the final class has a
move ctor or not. If it doesn't, then copy ctor is used and everything will
be copied, including any moveable subobjects.
GC> Is it even possible to ask the language in general to move an
GC> object and in no case to fall back on copying when the object
GC> is actually copyable? (Excluding, that is, special cases like
GC> unique_ptr that are specifically not copyable.) I'm thinking
GC> that this is not possible.
It is possible, and with C++20 it is much simpler than before as you can
just use "if constexpr (std::movable<class_name>)" instead of dealing with
SFINAE, but you still can't prevent the compiler from using the copy ctor
when writing class_name(reference_to_object) if this ctor is available.
Regards,
VZ
pgprqRxzJAae0.pgp
Description: PGP signature
- [lmi] const or reference members [Was: When in doubt, prefer the Rule of Five to the Rule of Zero], (continued)
- [lmi] Is this class moveable or not? [Was: master 6a59da54 8/8: When in doubt, prefer the Rule of Five to the Rule of Zero], Greg Chicares, 2022/07/12
- Re: [lmi] Is this class moveable or not?, Vadim Zeitlin, 2022/07/13
- Re: [lmi] Is this class moveable or not?, Greg Chicares, 2022/07/13
- [lmi] Move decays to copy [Was: When in doubt, prefer the Rule of Five to the Rule of Zero], Greg Chicares, 2022/07/12
- Re: [lmi] Move decays to copy, Vadim Zeitlin, 2022/07/12
- Re: [lmi] Move decays to copy, Greg Chicares, 2022/07/12
- Re: [lmi] Move decays to copy,
Vadim Zeitlin <=