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 2 of 2 — ← Prev page 1 [2]

#85501

20.07.2022 15:11 Anthony Capobianco kirjutas:
> 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.

+1

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

#85511

On 7/20/2022 2:11 PM, Anthony Capobianco wrote:
> 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.

Correct in this case, however the name of most standard functions 
describes what the functions do.

> 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.

Good explanation.
Still, the name "move" is somewhat problematic, if even Bjarne's 
description of the function has to explain from the very beginning that 
std::move doesn't move anything.

So, yes the name is not perfect, but alternatives could be worse, and we 
can live with not perfect.

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

#85521

Op 20.jul..2022 om 14:11 schreef Anthony Capobianco:
> 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.

That is in general difficult to implement, because it is not the dev 
using the function who give it a name, but the dev creating the function 
who defines the name. When creating a function it might not be clear in 
how many ways it can be used. Sometimes functions are used in unexpected 
ways, not foreseen when creating the function. Therefore, when creating 
a function, one usually give it a name according to what it does. If it 
has a name according to its intended use, it may become very confusing 
when it is used for other purposes.
That said, in this case it seems that it is very improbable that 
std::move will be used for other purposes than moving.

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

#85522

Anthony Capobianco <kiiwy112@gmail.com> wrote:
> 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. 

I think that the name 'std::move()' breaks more clarity conventions than
that.

'move()', as a verb, would indicate that the function itself does something,
in this case, that it does the moving. It would be completely concordant
with myriads of other such functions, like std::sort() (which itself does
the sorting), std::find() (which itself does the finding), std::copy()
(which itself does the copying) and so on.

Particularly that last one is extremely telling: Compare "std::copy()"
to "std::move()". They both sound, by their name, extraordinarily
closely related. It sounds like the former copies stuff from one
place to another (doing it itself), while the latter moves stuff
from one place to another (likewise doing it itself).

It would be highly bizarre if "std::copy()" would mean "this doesn't
actually copy anything, it just casts the parameter in such a manner
that it becomes copyable".

If the latter thing were needed, certainly it would be named something
clearer, like for example std::make_copyable(), or std::cast_to_copyable()
or something along those lines. Not just std::copy().

Likewise it would be highly bizarre if "std::sort()" did no sorting but
instead just somehow cast the parameter into something that can be sorted.

std::move() is extraordinarily unique among all standard library functions
in that it breaks this fundamental naming convention. Certainly someone
who knows well what std::copy() does but doesn't know what std::move()
does (but knows about move semantics) would assume that the latter does
the same thing as the former, but moving the elements instead of copying
them.

It can't even be a question of "move" being a short name. The standard
library doesn't shy away from using very long names if needed. Take for
example:

std::filesystem::recursive_directory_iterator::disable_recursion_pending()

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

#85523

21.07.2022 12:05 Juha Nieminen kirjutas:

> 
> Likewise it would be highly bizarre if "std::sort()" did no sorting but
> instead just somehow cast the parameter into something that can be sorted.

Yes, but e.g. std::unique() does not actually make a vector to contain 
unique values. Like std::move(), it is only intended to be used as one 
step toward the goal.

If moving was done by e.g. static_cast<T&&>(x), then each such code line 
would need a comment a la "moving the value". Think of std::move() as a 
replacement of this comment.

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

#85534

On 7/21/2022 2:05 AM, Juha Nieminen wrote:
> Anthony Capobianco <kiiwy112@gmail.com> wrote:
>> 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.
> 
> I think that the name 'std::move()' breaks more clarity conventions than
> that.
> 
> 'move()', as a verb, would indicate that the function itself does something,
> in this case, that it does the moving. It would be completely concordant
> with myriads of other such functions, like std::sort() (which itself does
> the sorting), std::find() (which itself does the finding), std::copy()
> (which itself does the copying) and so on.
> 
> Particularly that last one is extremely telling: Compare "std::copy()"
> to "std::move()". They both sound, by their name, extraordinarily
> closely related. It sounds like the former copies stuff from one
> place to another (doing it itself), while the latter moves stuff
> from one place to another (likewise doing it itself).
> 
> It would be highly bizarre if "std::copy()" would mean "this doesn't
> actually copy anything, it just casts the parameter in such a manner
> that it becomes copyable".
> 
> If the latter thing were needed, certainly it would be named something
> clearer, like for example std::make_copyable(), or std::cast_to_copyable()
> or something along those lines. Not just std::copy().
> 
> Likewise it would be highly bizarre if "std::sort()" did no sorting but
> instead just somehow cast the parameter into something that can be sorted.
> 
> std::move() is extraordinarily unique among all standard library functions
> in that it breaks this fundamental naming convention. Certainly someone
> who knows well what std::copy() does but doesn't know what std::move()
> does (but knows about move semantics) would assume that the latter does
> the same thing as the former, but moving the elements instead of copying
> them.
> 
> It can't even be a question of "move" being a short name. The standard
> library doesn't shy away from using very long names if needed. Take for
> example:
> 
> std::filesystem::recursive_directory_iterator::disable_recursion_pending()

Probably better would have been std::moveable() instead of std:move.

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

#85505

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?
> 
> 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? 

No.

 From the very beginning the concept of "moving" in C++ was designed 
with the following axiom in mind:

   Good-old classic copying is also a form of moving. Moving is a wider 
concept, an extension of copying. Copying in that sense is a "laziest" 
form of moving. ("Laziest" is a sense that it requires the last amount 
of learning: i.e. one can just keep copying as before, and call it "moving")

It is very important to understand that in C++ full-blown, completely 
non-destructive copying also qualifies as moving.

-- 
Best regards,
Andrey

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web