3 ms·

I feel like that's a pedantic detail. True, yes, but irrelevant. You may as well also point out that the return address is going to be copied to the instruction

I feel like that's a pedantic detail. True, yes, but irrelevant. You may as well also point out that the return address is going to be copied to the instruction pointer when the constructor returns.

jvanderbot 2y ago
It should be, but it's very much not in the real world at least as far as I've seen. Using std::move for anything other than "unique ownership without pointers" really messes things up. People put std::move everywhere expecting performance gains, just like we used to put "&" everywhere expecting performance gains. It's a bit of cargo cultism that can be nicely dispelled by realizing std::move is just std::copy with a compiler-defined constructor invocation potentially run to determine the old value. With that phrasing, it's hard to hallucinate performance gains that might come automatically.
- colejohnson66 2y ago
  In fact, using std::move everywhere can actually make your performance worse! https://devblogs.microsoft.com/oldnewthing/20231124-00/?p=109059 https://devblogs.microsoft.com/oldnewthing/20231124-00/?p=10...
- gpderetta 2y ago
  > std::move is just std::copy with a compiler-defined constructor invocation potentially run to determine the old value I have no idea what that means. std::move is a cast to an rvalue reference. That can potentially trigger a specific overloaded function to be selected and possibly, ultimately, a move constructor or assignment operator to be called. For an explicit move to be profitable, an expression would have otherwise chosen a copy constructor for a type with an expensive copy constructor and a cheap move constructor. std::copy is a range algorithm, not sure what's the relevance.
  - jvanderbot 2y ago
    Yes, typed too fast. I meant the explicit copy constructor. Luckly, HN will hide my garbage text quickly enough. Thanks for the correction!
Asraelite 2y ago
I think it's a worthwhile distinction to bring up because it highlights a common misconception people have about strings and vectors. A string value is not the string content itself, just a small struct containing a pointer and other metadata. If we're talking about the in-depth semantics of a language then it's important to point out that this struct is the string, and the array of UTF-8 characters it points to is not. C++ obfuscates this distinction because of how it automatically deep copies vectors and strings for you in many cases.
- epcoa 2y ago
  > then it's important to point out that this struct is the string, and the array of UTF-8 characters it points to is not. So then under this model, what’s the difference between a string and a string_view?
  - Asraelite 2y ago
    ...one is a string and one is a string view? I'm not sure what you're getting at. They're both small structs holding pointers to char data, they just operate on that data differently.
    - Maxatar 2y ago
      Exactly, thinking about things in terms of their implementations is usually not a good way to actually understand what that thing is. By arguing that std::string is just the struct itself, which consists of who knows what... you fail to appreciate the actual semantics of std::string and how those semantics are really what defines the std::string. std::string_view also has implementation details that in principle could be similar to std::string, it's a pointer with a size, but the semantics of std::string_view are very different from the semantics of std::string. And that's the crux of the issue, it's better to understand classes in terms of their semantics, how they operate, rather than their implementations. Implementations can change, and two very separate things can have the same or very similar implementations. A std::string is not just some pointers and some record keeping data; a std::string is best understood as a class used to own and manage a sequence of characters with the various operations that one would expect for such management. A std::string_view is non-owning, read-only variation of such a class that operates on an existing sequence of characters. How these are implemented and their structural details is not really what's important, it's how someone is expected to use them and what can be done with them that counts.
quietbritishjim 2y ago
It's a real semantic difference, not a pedantic detail: It means that there is a practical reason that the moved-from object could be non-empty. A few standard library types do guarantee that the moved-from object is empty (e.g., the smart pointer types). For some others (basically, all containers except string), it is not explicitly stated that this is the case but it is hard to imagine an implementation that doesn't (due to time complexity and iterator invalidation rules). Arguably, this represents a bigger risk than string'e behaviour, but it's still interesting.
- fluoridation 2y ago
  >It's a real semantic difference, not a pedantic detail What's the semantic difference? Of course moving a class will involve some amount of copying. How could it be any other way? If you have something like struct { int a[1000]; }, how are you supposed to move the contents of the struct without copying anything? What, you take a pair of really tiny scissors and cut a teeny tiny piece of the RAM, then glue the capacitors somewhere else?
  - Joker_vD 2y ago
    > how are you supposed to move the contents of the struct without copying anything? By taking the physical page this one struct resides in, and mapping it into the virtual address space the second time. This approach is usually used in the kernel-level development, but there has been a lot of research done since the seventies on how to use it in runtimes for high-level programming languages. Now, it does involve copying an address of this struct from one place to another, that I cede.
    - fluoridation 2y ago
      Sure. At the cost of needing >=4K per object, since otherwise "moving" an object involves also moving the other objects sharing the same page.

I feel like that's a pedantic detail. True, yes, but irrelevant. You may as well also point out that the return address is going to be copied to the instruction pointer when the constructor returns.

jvanderbot 2y ago

It should be, but it's very much not in the real world at least as far as I've seen. Using std::move for anything other than "unique ownership without pointers" really messes things up. People put std::move everywhere expecting performance gains, just like we used to put "&" everywhere expecting performance gains. It's a bit of cargo cultism that can be nicely dispelled by realizing std::move is just std::copy with a compiler-defined constructor invocation potentially run to determine the old value. With that phrasing, it's hard to hallucinate performance gains that might come automatically.

colejohnson66 2y ago
In fact, using std::move everywhere can actually make your performance worse! https://devblogs.microsoft.com/oldnewthing/20231124-00/?p=109059 https://devblogs.microsoft.com/oldnewthing/20231124-00/?p=10...
gpderetta 2y ago
> std::move is just std::copy with a compiler-defined constructor invocation potentially run to determine the old value I have no idea what that means. std::move is a cast to an rvalue reference. That can potentially trigger a specific overloaded function to be selected and possibly, ultimately, a move constructor or assignment operator to be called. For an explicit move to be profitable, an expression would have otherwise chosen a copy constructor for a type with an expensive copy constructor and a cheap move constructor. std::copy is a range algorithm, not sure what's the relevance.
- jvanderbot 2y ago
  Yes, typed too fast. I meant the explicit copy constructor. Luckly, HN will hide my garbage text quickly enough. Thanks for the correction!

Asraelite 2y ago

I think it's a worthwhile distinction to bring up because it highlights a common misconception people have about strings and vectors. A string value is not the string content itself, just a small struct containing a pointer and other metadata. If we're talking about the in-depth semantics of a language then it's important to point out that this struct is the string, and the array of UTF-8 characters it points to is not. C++ obfuscates this distinction because of how it automatically deep copies vectors and strings for you in many cases.

epcoa 2y ago
> then it's important to point out that this struct is the string, and the array of UTF-8 characters it points to is not. So then under this model, what’s the difference between a string and a string_view?
- Asraelite 2y ago
  ...one is a string and one is a string view? I'm not sure what you're getting at. They're both small structs holding pointers to char data, they just operate on that data differently.
  - Maxatar 2y ago
    Exactly, thinking about things in terms of their implementations is usually not a good way to actually understand what that thing is. By arguing that std::string is just the struct itself, which consists of who knows what... you fail to appreciate the actual semantics of std::string and how those semantics are really what defines the std::string. std::string_view also has implementation details that in principle could be similar to std::string, it's a pointer with a size, but the semantics of std::string_view are very different from the semantics of std::string. And that's the crux of the issue, it's better to understand classes in terms of their semantics, how they operate, rather than their implementations. Implementations can change, and two very separate things can have the same or very similar implementations. A std::string is not just some pointers and some record keeping data; a std::string is best understood as a class used to own and manage a sequence of characters with the various operations that one would expect for such management. A std::string_view is non-owning, read-only variation of such a class that operates on an existing sequence of characters. How these are implemented and their structural details is not really what's important, it's how someone is expected to use them and what can be done with them that counts.

quietbritishjim 2y ago

It's a real semantic difference, not a pedantic detail: It means that there is a practical reason that the moved-from object could be non-empty. A few standard library types do guarantee that the moved-from object is empty (e.g., the smart pointer types). For some others (basically, all containers except string), it is not explicitly stated that this is the case but it is hard to imagine an implementation that doesn't (due to time complexity and iterator invalidation rules). Arguably, this represents a bigger risk than string'e behaviour, but it's still interesting.

fluoridation 2y ago
>It's a real semantic difference, not a pedantic detail What's the semantic difference? Of course moving a class will involve some amount of copying. How could it be any other way? If you have something like struct { int a[1000]; }, how are you supposed to move the contents of the struct without copying anything? What, you take a pair of really tiny scissors and cut a teeny tiny piece of the RAM, then glue the capacitors somewhere else?
- Joker_vD 2y ago
  > how are you supposed to move the contents of the struct without copying anything? By taking the physical page this one struct resides in, and mapping it into the virtual address space the second time. This approach is usually used in the kernel-level development, but there has been a lot of research done since the seventies on how to use it in runtimes for high-level programming languages. Now, it does involve copying an address of this struct from one place to another, that I cede.
  - fluoridation 2y ago
    Sure. At the cost of needing >=4K per object, since otherwise "moving" an object involves also moving the other objects sharing the same page.