Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Notifications
Mark all as read
Q&A

Post History

#4: Post edited by user avatar Dirk Herrmann‭ · 2022-07-20T06:58:29Z (2 months ago)
Distinguished the general case and the case where it is known there are no side effects.
  • The substitution of the call to a copy constructor by a call to a move constructor could lead to a different behavior: The two constructors might have different side effects. Thus, such an optimization might result in a different behavior of the compiled code.
  • This is normally not accepted for optimizations: The normal assumption is, that an optimization may have an impact on performance or memory consumption, but does not change the behavior otherwise. (Side note: A special situation is, when the code does not strictly comply with the language rules anyway and therefore formally has undefined behavior, but that's a special case...)
  • For C++, however, there are some exceptions to this usual approach to optimization: In clearly specified circumstances the compiler is allowed (or even mandated) to eliminate copy/move operations even if that results in different behavior, see https://en.cppreference.com/w/cpp/language/copy_elision.
  • Still, in all other situations (including the one that you have described), optimizations shall not alter the behavior. This means that **the compiler is not allowed to implicitly substitute the copy by the move operation in your case**.
  • Update: Distinguished between the general case and cases (as with `std::string`) where it is known that there are no side effects.
  • In the general case, the substitution of the call to a copy constructor by a call to a move constructor could lead to a different behavior: The two constructors might have different side effects. Thus, such an optimization might result in a different behavior of the compiled code.
  • This is normally not accepted for optimizations: The normal assumption is, that an optimization may have an impact on performance or memory consumption, but does not change the behavior otherwise. (Side note: A special situation is, when the code does not strictly comply with the language rules anyway and therefore formally has undefined behavior, but that's a special case...)
  • For C++, however, there are some exceptions to this usual approach to optimization: In clearly specified circumstances the compiler is allowed (or even mandated) to eliminate copy/move operations even if that results in different behavior, see https://en.cppreference.com/w/cpp/language/copy_elision.
  • Still, in all other situations, optimizations shall not alter the behavior. This means that **the compiler is not generally allowed to implicitly substitute the copy by the move operation**.
  • In your example, however, you are dealing with `std::string`. As `std::string` is defined by the standard, the compiler knows, that there are no side effects in the constructors. In such cases, where it is known there are no side effects, the compiler can perform all kinds of optimizations, including (but not limited to) replacing copy by move operations.
#3: Post edited by user avatar Alexei‭ · 2022-07-15T12:19:29Z (3 months ago)
highlighted the core answer for the question (TL;DR)
  • The substitution of the call to a copy constructor by a call to a move constructor could lead to a different behavior: The two constructors might have different side effects. Thus, such an optimization might result in a different behavior of the compiled code.
  • This is normally not accepted for optimizations: The normal assumption is, that an optimization may have an impact on performance or memory consumption, but does not change the behavior otherwise. (Side note: A special situation is, when the code does not strictly comply with the language rules anyway and therefore formally has undefined behavior, but that's a special case...)
  • For C++, however, there are some exceptions to this usual approach to optimization: In clearly specified circumstances the compiler is allowed (or even mandated) to eliminate copy/move operations even if that results in different behavior, see https://en.cppreference.com/w/cpp/language/copy_elision.
  • Still, in all other situations (including the one that you have described), optimizations shall not alter the behavior. Which means, the compiler is not allowed to implicitly substitute the copy by the move operation in your case.
  • The substitution of the call to a copy constructor by a call to a move constructor could lead to a different behavior: The two constructors might have different side effects. Thus, such an optimization might result in a different behavior of the compiled code.
  • This is normally not accepted for optimizations: The normal assumption is, that an optimization may have an impact on performance or memory consumption, but does not change the behavior otherwise. (Side note: A special situation is, when the code does not strictly comply with the language rules anyway and therefore formally has undefined behavior, but that's a special case...)
  • For C++, however, there are some exceptions to this usual approach to optimization: In clearly specified circumstances the compiler is allowed (or even mandated) to eliminate copy/move operations even if that results in different behavior, see https://en.cppreference.com/w/cpp/language/copy_elision.
  • Still, in all other situations (including the one that you have described), optimizations shall not alter the behavior. This means that **the compiler is not allowed to implicitly substitute the copy by the move operation in your case**.
#2: Post edited by user avatar Dirk Herrmann‭ · 2022-07-14T22:15:32Z (3 months ago)
  • The substitution of the call to a copy constructor by a call to a move constructor could lead to a different behavior: The two constructors might have different side effects. Thus, such an optimization might result in a different behavior of the compiled code.
  • This is normally not accepted for optimizations: The normal assumption is, that an optimization may have an impact on performance or memory consumption, but does not change the behavior otherwise. (Side note: A special situation is, when the code does not strictly comply with the language rules anyway and therefore formally has undefined behavior, but that's a special case...)
  • For C++, however, there are some exceptions to this usual approach to optimization: In clearly specified circumstances the compiler is allowed (or even mandated) to eliminate copy/move operations even if that results in different behavior, see https://en.cppreference.com/w/cpp/language/copy_elision.
  • Still, in all other situations (including the one that you have described), optimizations shall not alter the behavior. Which means, the compiler is not allowed to implicitly substitute the copy by the move operation.
  • The substitution of the call to a copy constructor by a call to a move constructor could lead to a different behavior: The two constructors might have different side effects. Thus, such an optimization might result in a different behavior of the compiled code.
  • This is normally not accepted for optimizations: The normal assumption is, that an optimization may have an impact on performance or memory consumption, but does not change the behavior otherwise. (Side note: A special situation is, when the code does not strictly comply with the language rules anyway and therefore formally has undefined behavior, but that's a special case...)
  • For C++, however, there are some exceptions to this usual approach to optimization: In clearly specified circumstances the compiler is allowed (or even mandated) to eliminate copy/move operations even if that results in different behavior, see https://en.cppreference.com/w/cpp/language/copy_elision.
  • Still, in all other situations (including the one that you have described), optimizations shall not alter the behavior. Which means, the compiler is not allowed to implicitly substitute the copy by the move operation in your case.
#1: Initial revision by user avatar Dirk Herrmann‭ · 2022-07-14T22:13:13Z (3 months ago)
The substitution of the call to a copy constructor by a call to a move constructor could lead to a different behavior: The two constructors might have different side effects.  Thus, such an optimization might result in a different behavior of the compiled code.

This is normally not accepted for optimizations: The normal assumption is, that an optimization may have an impact on performance or memory consumption, but does not change the behavior otherwise.  (Side note: A special situation is, when the code does not strictly comply with the language rules anyway and therefore formally has undefined behavior, but that's a special case...)

For C++, however, there are some exceptions to this usual approach to optimization: In clearly specified circumstances the compiler is allowed (or even mandated) to eliminate copy/move operations even if that results in different behavior, see https://en.cppreference.com/w/cpp/language/copy_elision.

Still, in all other situations (including the one that you have described), optimizations shall not alter the behavior.  Which means, the compiler is not allowed to implicitly substitute the copy by the move operation.