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

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

Is std::move() a misleading misnomer?

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

Contents

  Is std::move() a misleading misnomer? Juha Nieminen <nospam@thanks.invalid> - 2022-07-15 12:02 +0000
    Re: Is std::move() a misleading misnomer? Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-15 14:43 +0200
    Re: Is std::move() a misleading misnomer? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-07-15 06:18 -0700
      Re: Is std::move() a misleading misnomer? Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-15 19:09 +0200
    Re: Is std::move() a misleading misnomer? Bo Persson <bo@bo-persson.se> - 2022-07-15 16:01 +0200
      Re: Is std::move() a misleading misnomer? Juha Nieminen <nospam@thanks.invalid> - 2022-07-16 18:21 +0000
        Re: Is std::move() a misleading misnomer? Bo Persson <bo@bo-persson.se> - 2022-07-16 21:11 +0200
          Re: Is std::move() a misleading misnomer? Juha Nieminen <nospam@thanks.invalid> - 2022-07-17 14:28 +0000
    Re: Is std::move() a misleading misnomer? Gawr Gura <gawrgura@mail.hololive.com> - 2022-07-15 08:34 -0700
    Re: Is std::move() a misleading misnomer? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2022-07-15 16:03 +0000
      Re: Is std::move() a misleading misnomer? Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-15 19:12 +0200
        Re: Is std::move() a misleading misnomer? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2022-07-16 19:24 +0000
    Re: Is std::move() a misleading misnomer? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-07-15 23:08 +0200
    Re: Is std::move() a misleading misnomer? Paavo Helde <eesnimi@osa.pri.ee> - 2022-07-16 11:48 +0300
    Re: Is std::move() a misleading misnomer? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-16 16:31 -0700
      Re: Is std::move() a misleading misnomer? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-07-16 18:32 -0700
        Re: Is std::move() a misleading misnomer? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-19 16:41 -0700
    Re: Is std::move() a misleading misnomer? wij <wyniijj2@gmail.com> - 2022-07-18 16:14 -0700
      Re: Is std::move() a misleading misnomer? Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-19 07:59 +0200
    Re: Is std::move() a misleading misnomer? Anthony Capobianco <kiiwy112@gmail.com> - 2022-07-20 05:11 -0700
      Re: Is std::move() a misleading misnomer? Paavo Helde <eesnimi@osa.pri.ee> - 2022-07-20 15:26 +0300
      Re: Is std::move() a misleading misnomer? Manfred <noname@add.invalid> - 2022-07-21 01:16 +0200
      Re: Is std::move() a misleading misnomer? "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2022-07-21 09:47 +0200
      Re: Is std::move() a misleading misnomer? Juha Nieminen <nospam@thanks.invalid> - 2022-07-21 09:05 +0000
        Re: Is std::move() a misleading misnomer? Paavo Helde <eesnimi@osa.pri.ee> - 2022-07-21 13:12 +0300
        Re: Is std::move() a misleading misnomer? red floyd <no.spam.here@its.invalid> - 2022-07-21 13:09 -0700
    Re: Is std::move() a misleading misnomer? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-07-20 13:08 -0700

Page 1 of 2  [1] 2  Next page →

#85234 — Is std::move() a misleading misnomer?

Let's take a relatively simple line of code:

    v1 = std::move(v2);

What does that do? Well, we know for certain (at least if the type of 'v1'
and 'v2' has been logically implemented) that 'v1' will contain what
'v2' contained before this statement.

But what will 'v2' contain?

It depends. (More particularly, it depends on whether the type in
question implements a move assignment operator, and it has been
implemented in the recommended way.)

But should it really depend on anything? Isn't that statement
expressing the desire to *move* the contents of 'v2' into 'v1',
thus leaving 'v2' empty? (Even if under the hood a deep copy
is being done instead, consistency of behavior would dictate
for 'v2' to become empty nevertheless.)

The fact is that if we don't know the type of 'v1' and 'v2'
we cannot assume that 'v2' will be empty.

Since std::move() does not guarantee that the contents will be
moved, isn't it quite a misnomer?

std::to_rvalue() might be more cryptic, but at least it would
express much better what it's actually doing.

[toc] | [next] | [standalone]

#85236

Am 15.07.2022 um 14:02 schrieb Juha Nieminen:

> Let's take a relatively simple line of code:
> 
>      v1 = std::move(v2);
> 
> What does that do? Well, we know for certain (at least if the type of 'v1'
> and 'v2' has been logically implemented) that 'v1' will contain what
> 'v2' contained before this statement.
> 
> But what will 'v2' contain?
> 
> It depends. (More particularly, it depends on whether the type in
> question implements a move assignment operator, and it has been
> implemented in the recommended way.)
> 
> But should it really depend on anything? Isn't that statement
> expressing the desire to *move* the contents of 'v2' into 'v1',
> thus leaving 'v2' empty? (Even if under the hood a deep copy
> is being done instead, consistency of behavior would dictate
> for 'v2' to become empty nevertheless.)
> 
> The fact is that if we don't know the type of 'v1' and 'v2'
> we cannot assume that 'v2' will be empty.
> 
> Since std::move() does not guarantee that the contents will be
> moved, isn't it quite a misnomer?
> 
> std::to_rvalue() might be more cryptic, but at least it would
> express much better what it's actually doing.

That actually only does happen when v1 is a templated data type.
Otherwise you'll know whether v1 has a move assignment operator.
If it dosn't that's actually only a performance problem, but not
a semantical problem since you can expect the copy assignment
operator to make a copy.

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

#85237

On Friday, 15 July 2022 at 13:02:28 UTC+1, Juha Nieminen wrote:
> Let's take a relatively simple line of code: 
> 
> v1 = std::move(v2); 
> 
> What does that do? Well, we know for certain (at least if the type of 'v1' 
> and 'v2' has been logically implemented) that 'v1' will contain what 
> 'v2' contained before this statement. 
> 
> But what will 'v2' contain? 
> 
> It depends. (More particularly, it depends on whether the type in 
> question implements a move assignment operator, and it has been 
> implemented in the recommended way.) 
> 
> But should it really depend on anything? Isn't that statement 
> expressing the desire to *move* the contents of 'v2' into 'v1', 
> thus leaving 'v2' empty? (Even if under the hood a deep copy 
> is being done instead, consistency of behavior would dictate 
> for 'v2' to become empty nevertheless.) 
> 
> The fact is that if we don't know the type of 'v1' and 'v2' 
> we cannot assume that 'v2' will be empty. 
> 
> Since std::move() does not guarantee that the contents will be 
> moved, isn't it quite a misnomer? 
> 
> std::to_rvalue() might be more cryptic, but at least it would 
> express much better what it's actually doing.
>
It doesn't actually move it.
But v2 become invalid. Move assignments of big objects are often
implemented as swaps. You exchange a few pointers and v1 becomes
equal to v2. But you don't guarantee this because it is a side-effect
rather than the operation you want.

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

#85253

Am 15.07.2022 um 15:18 schrieb Malcolm McLean:

> It doesn't actually move it.
> But v2 become invalid. Move assignments of big objects are often
> implemented as swaps. ...

std::swap uses move-semantics if implemented by the object to be
swapped (move constructor and move assignment operator). But moves
themselfes are usually not implemented as swaps.

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

#85238

On 2022-07-15 at 14:02, Juha Nieminen wrote:
> Let's take a relatively simple line of code:
> 
>      v1 = std::move(v2);
> 
> What does that do? Well, we know for certain (at least if the type of 'v1'
> and 'v2' has been logically implemented) that 'v1' will contain what
> 'v2' contained before this statement.
> 
> But what will 'v2' contain?


Why do we care? You move from v2 when you don't need to use its value 
anymore.

> 
> It depends. (More particularly, it depends on whether the type in
> question implements a move assignment operator, and it has been
> implemented in the recommended way.)
> 
> But should it really depend on anything? Isn't that statement
> expressing the desire to *move* the contents of 'v2' into 'v1',
> thus leaving 'v2' empty? (Even if under the hood a deep copy
> is being done instead, consistency of behavior would dictate
> for 'v2' to become empty nevertheless.)

If you pass v2 as a parameter to some other function (or constructor) 
just before v2 goes out of scope, why spend time making it "empty" just 
before it goes out of scope?


> 
> The fact is that if we don't know the type of 'v1' and 'v2'
> we cannot assume that 'v2' will be empty.

No we cannot. So what?

> 
> Since std::move() does not guarantee that the contents will be
> moved, isn't it quite a misnomer?
> 
> std::to_rvalue() might be more cryptic, but at least it would
> express much better what it's actually doing.

There has been proposals for more "obvious" names like enable_move or 
allow_move, or make_movable. But they all suffer from the problem of 
being a lot longer to type. And not much easier to read.

So "move" has the advantage of being short. We just have to learn what 
it means. Can't be much harder than to figure out what constexpr or 
decltype means.

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

#85366

Bo Persson <bo@bo-persson.se> wrote:
> There has been proposals for more "obvious" names like enable_move or 
> allow_move, or make_movable. But they all suffer from the problem of 
> being a lot longer to type.

And that's a problem because...

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

#85372

On 2022-07-16 at 20:21, Juha Nieminen wrote:
> Bo Persson <bo@bo-persson.se> wrote:
>> There has been proposals for more "obvious" names like enable_move or
>> allow_move, or make_movable. But they all suffer from the problem of
>> being a lot longer to type.
> 
> And that's a problem because...

Because std::move(x) is a shorthand for static_cast<T&&>(x) and one 
important criteria for a shorthand is that is should be shorter.

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

#85432

Bo Persson <bo@bo-persson.se> wrote:
> On 2022-07-16 at 20:21, Juha Nieminen wrote:
>> Bo Persson <bo@bo-persson.se> wrote:
>>> There has been proposals for more "obvious" names like enable_move or
>>> allow_move, or make_movable. But they all suffer from the problem of
>>> being a lot longer to type.
>> 
>> And that's a problem because...
> 
> Because std::move(x) is a shorthand for static_cast<T&&>(x) and one 
> important criteria for a shorthand is that is should be shorter.

I have never subscribed to the "brevity over clarity" principle of
programming (which seems awfully popular).

You cannot compare two extremes and argue that the shorter extreme
is better because it's shorter, without taking into account the
middle possibilities that are clearer than both extremes.

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

#85246

> It depends. (More particularly, it depends on whether the type in
> question implements a move assignment operator, and it has been
> implemented in the recommended way.)

Isn't this functionally true of most lines of a C++ program? Between
template specialization, overloading, and user defined implicit casts 
there are a lot of ways to make something that seems straight forward
behave in a roundabout way. Why should it matter that the move
assignment operator might behave in such a way?

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

#85249

On Fri, 2022-07-15, Juha Nieminen wrote:
> Let's take a relatively simple line of code:
>
>     v1 = std::move(v2);
...
> Since std::move() does not guarantee that the contents will be
> moved, isn't it quite a misnomer?
>
> std::to_rvalue() might be more cryptic, but at least it would
> express much better what it's actually doing.

I'm pretty sure Stroustrup writes, when he documents std::move in
TC++PL, that he would have preferred a name similar to to_rvalue().

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#85254

Am 15.07.2022 um 18:03 schrieb Jorgen Grahn:

> I'm pretty sure Stroustrup writes, when he documents std::move in
> TC++PL, that he would have preferred a name similar to to_rvalue().

I never read that in that book and I currently can't find that neither
in the German nor in the English version. I think that move is simply
semantically sufficient and there are no needs to further emphasize
this in another name.

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

#85373

On Fri, 2022-07-15, Bonita Montero wrote:
> Am 15.07.2022 um 18:03 schrieb Jorgen Grahn:
>
>> I'm pretty sure Stroustrup writes, when he documents std::move in
>> TC++PL, that he would have preferred a name similar to to_rvalue().
>
> I never read that in that book and I currently can't find that neither
> in the German nor in the English version.

Fourth edition, page 516, 17.5.2. "It would have been better if move()
had been called rval(), but ...".

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#85296

On 15 Jul 2022 14:02, Juha Nieminen wrote:
> Let's take a relatively simple line of code:
> 
>      v1 = std::move(v2);
> 
> What does that do? Well, we know for certain (at least if the type of 'v1'
> and 'v2' has been logically implemented) that 'v1' will contain what
> 'v2' contained before this statement.
> 
> But what will 'v2' contain?
> 
> It depends. (More particularly, it depends on whether the type in
> question implements a move assignment operator, and it has been
> implemented in the recommended way.)
> 
> But should it really depend on anything? Isn't that statement
> expressing the desire to *move* the contents of 'v2' into 'v1',
> thus leaving 'v2' empty? (Even if under the hood a deep copy
> is being done instead, consistency of behavior would dictate
> for 'v2' to become empty nevertheless.)
> 
> The fact is that if we don't know the type of 'v1' and 'v2'
> we cannot assume that 'v2' will be empty.
> 
> Since std::move() does not guarantee that the contents will be
> moved, isn't it quite a misnomer?

Yes, it misleads people. In particular students.


> std::to_rvalue() might be more cryptic, but at least it would
> express much better what it's actually doing.

Well, consider `std::to_movable`.

It would IMO be a good alternate or replacement name for `std::move`, 
because unlike the verb it just expresses a potential, a potential that 
may or may not manifest depending on the types.

Unfortunately the shorter name `std::movable` is now taken by a C++20 
concept.

- Alf

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

#85343

15.07.2022 15:02 Juha Nieminen kirjutas:
> Let's take a relatively simple line of code:
> 
>      v1 = std::move(v2);
> 
> What does that do? Well, we know for certain (at least if the type of 'v1'
> and 'v2' has been logically implemented) that 'v1' will contain what
> 'v2' contained before this statement.
> 
> But what will 'v2' contain?
> 
> It depends. (More particularly, it depends on whether the type in
> question implements a move assignment operator, and it has been
> implemented in the recommended way.)

Yes, it is a bit misleading name, but not so much as e.g. "static" or 
"inline" ;-)

That's also why when I'm implementing move ctor/assignment for my 
classes, I always take care to make v2 properly "empty" even when not 
needed technically, just for consistency.

In general one shouldn't care about what state v2 is left in, so the 
issue is moot.

In case I care, e.g. when preparing a data structure containing 
single-threaded smart pointers to be sent over to another thread, I add 
an extra assert line to be sure the move actually emptied v2.

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

#85379

On 7/15/2022 5:02 AM, Juha Nieminen wrote:
> Let's take a relatively simple line of code:
> 
>      v1 = std::move(v2);
> 
> What does that do? Well, we know for certain (at least if the type of 'v1'
> and 'v2' has been logically implemented) that 'v1' will contain what
> 'v2' contained before this statement.
> 
> But what will 'v2' contain?

For some reason, I thought of a move from v2 to v1 leaves v2 in an 
undefined zombie state where accessing v2 is undefined behavior because 
its now "dead"?



> 
> It depends. (More particularly, it depends on whether the type in
> question implements a move assignment operator, and it has been
> implemented in the recommended way.)
> 
> But should it really depend on anything? Isn't that statement
> expressing the desire to *move* the contents of 'v2' into 'v1',
> thus leaving 'v2' empty? (Even if under the hood a deep copy
> is being done instead, consistency of behavior would dictate
> for 'v2' to become empty nevertheless.)
> 
> The fact is that if we don't know the type of 'v1' and 'v2'
> we cannot assume that 'v2' will be empty.
> 
> Since std::move() does not guarantee that the contents will be
> moved, isn't it quite a misnomer?
> 
> std::to_rvalue() might be more cryptic, but at least it would
> express much better what it's actually doing.

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

#85386

On Sunday, 17 July 2022 at 00:31:23 UTC+1, Chris M. Thomasson wrote:
> On 7/15/2022 5:02 AM, Juha Nieminen wrote: 
> > Let's take a relatively simple line of code: 
> > 
> > v1 = std::move(v2); 
> > 
> > What does that do? Well, we know for certain (at least if the type of 'v1' 
> > and 'v2' has been logically implemented) that 'v1' will contain what 
> > 'v2' contained before this statement. 
> > 
> > But what will 'v2' contain?
> For some reason, I thought of a move from v2 to v1 leaves v2 in an 
> undefined zombie state where accessing v2 is undefined behavior because 
> its now "dead"?
>
That's more or less right. v2 has to be put into a valid state. So the destructor
must work. Also, it can be assigned to, and I believe that the assignment operator
must work.
But it can be and commonly is in a null state. However that shouldn't be treated as
guaranteed. An employee class might contain no employees, it might contain
one employee, or it might contain the full list of employees (the move assignment
was in fact implemented as a copy) or it might contain v1's list of employees
(the move assignment was implemented as a pointer swap).
It not really a case of UB. It's about the implied contract the move assignment
operator makes. 

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

#85485

On 7/16/2022 6:32 PM, Malcolm McLean wrote:
> On Sunday, 17 July 2022 at 00:31:23 UTC+1, Chris M. Thomasson wrote:
>> On 7/15/2022 5:02 AM, Juha Nieminen wrote:
>>> Let's take a relatively simple line of code:
>>>
>>> v1 = std::move(v2);
>>>
>>> What does that do? Well, we know for certain (at least if the type of 'v1'
>>> and 'v2' has been logically implemented) that 'v1' will contain what
>>> 'v2' contained before this statement.
>>>
>>> But what will 'v2' contain?
>> For some reason, I thought of a move from v2 to v1 leaves v2 in an
>> undefined zombie state where accessing v2 is undefined behavior because
>> its now "dead"?
>>
> That's more or less right. v2 has to be put into a valid state. So the destructor
> must work. Also, it can be assigned to, and I believe that the assignment operator
> must work.
> But it can be and commonly is in a null state. However that shouldn't be treated as
> guaranteed. An employee class might contain no employees, it might contain
> one employee, or it might contain the full list of employees (the move assignment
> was in fact implemented as a copy) or it might contain v1's list of employees
> (the move assignment was implemented as a pointer swap).


> It not really a case of UB. It's about the implied contract the move assignment
> operator makes.

Okay. That makes sense. Thank you.

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

#85468

On Friday, 15 July 2022 at 20:02:28 UTC+8, Juha Nieminen wrote:
> Let's take a relatively simple line of code: 
> 
> v1 = std::move(v2); 
> 
> What does that do? Well, we know for certain (at least if the type of 'v1' 
> and 'v2' has been logically implemented) that 'v1' will contain what 
> 'v2' contained before this statement. 
> 
> But what will 'v2' contain? 
> 
> It depends. (More particularly, it depends on whether the type in 
> question implements a move assignment operator, and it has been 
> implemented in the recommended way.) 
> 
> But should it really depend on anything? Isn't that statement 
> expressing the desire to *move* the contents of 'v2' into 'v1', 
> thus leaving 'v2' empty? (Even if under the hood a deep copy 
> is being done instead, consistency of behavior would dictate 
> for 'v2' to become empty nevertheless.) 
> 
> The fact is that if we don't know the type of 'v1' and 'v2' 
> we cannot assume that 'v2' will be empty. 
> 
> Since std::move() does not guarantee that the contents will be 
> moved, isn't it quite a misnomer? 
> 
> std::to_rvalue() might be more cryptic, but at least it would 
> express much better what it's actually doing.

From my perspective, the committee seemed urgent to standardize what the
'move ctor' means. Like always(?), the committee likes to show it always has a 
better resolution (unproven, e.g. std::endl) then requested.

General rule: Complexity don't go away.
C++ statement can be shorter (or smarter, whatever), but the 'hidden' comments 
become longer, the 'comment' can be shorter if put into 'standard'. To understand
'standard', one has to expand 'comment' to, say, ordinary/original form...
... Complexity is just moved around, won't disappear. (another case is in the error handling).
The rule applies to almost anything. IMO, the goal should be 'efficiency'.

Snippet of the manpage of the move ctor for template class Array (written before 2006):
No issues of rref. The only problem encountered is with classes like BigInt
BitInt::operator=(T) when T is arithmetic types, lots of overloads are needed.
But such needs are never demanding enough (IMO) for a core language change 
to add rref.

       Array(Array& src, ByMove_t)

           Move semantics of src to this pointed address.

           After function completed, src is regarded non-existant.
           The space occupied by src can be recycled. The dummy argument type
           ByMove_t acts as a function signature, use instance should always
           be ByMove. This member is supposed to be invoked only via
           placement new or in member initialization list, not to be
           explicitly called otherwise.

           This member is not entirely a real constructor (no new object is
           ever created, so it is called move) but a function in constructor
           form to support object movement in a dynamic array.

           Note: Except in member initialization list, src must be
                 a whole type, not reference to a base. Otherwise,
                 effect is undefined.

           Note: In cases element type T is a class that can use ::memcpy(2)
                 to do the job, user needs to provide a template
                 Wy::TypeTrait<T> overload, e.g.

                 template<> struct Wy::TypeTrait<T> {
                   static constexpr bool memcpy_able=true;
                   static constexpr bool memset_able=false;
                 };

           [Effect]
                 size()= src.size()
             capacity()= src.capacity()
                begin()= src.begin()
                  end()= src.end()

                   At final, object src does not exist

           Example:
             class D : public B {      // assume B has the move constructor
                  struct timespec m_ts;
                  char* m_ptr;         // pointed to allocated memory
                public:
                  D(D& d, ByMove_t)
                   : B(d,ByMove), m_ts(d.m_ts), m_ptr(d.m_ptr) {};
             };

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

#85472

Reads like someone who actually feels also unsettled by something like
that, but who wants to show others that he can understand the decisions
of the committee in order to make himself believe that he stands above
this.

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

#85500

On Friday, July 15, 2022 at 2:02:28 PM UTC+2, Juha Nieminen wrote:
> Since std::move() does not guarantee that the contents will be 
> moved, isn't it quite a misnomer? 
> 
> std::to_rvalue() might be more cryptic, but at least it would 
> express much better what it's actually doing.

The name of the function doesn't describe what it does, it describes the intent of a dev using it.  
You use it when you intend to move something. If you only intend to make it an rvalue reference, then you can cast it.
The intent is different. The compiler doesn't care what you call it, your coworkers might. 

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web