Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
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 constru...
Answer
#4: Post edited
by
Dirk Herrmann
·
2022-07-20T06:58:29Z (over 2 years 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
Alexei
·
2022-07-15T12:19:29Z (over 2 years 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
Dirk Herrmann
·
2022-07-14T22:15:32Z (over 2 years 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
Dirk Herrmann
·
2022-07-14T22:13:13Z (over 2 years 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.