This const Might Disable Move Semantics

Added: 2026-05-16

[00:00:00]Take a look at this function on the screen. At first glance, it seems completely fine. In fact, this kind of code is very common in many C++ projects. Why? Because many people think returning const is safer. It prevents others from arbitrarily modifying the return value. And they even believe that the more const you add, the more professional the code looks. Sounds reasonable, right? But in modern C++, this seemingly harmless const can actually make your code slower. So, why is that? Take a look at this piece of code. Under normal circumstances, modern C++ tries to avoid unnecessary copies as much as possible. If possible, the compiler will directly move this temporary object instead of copying it.

[00:00:36]And the overhead of moving is usually much smaller than copying. But here's the problem. The move constructor typically looks like this. It takes a non-const rvalue reference. Why must it be non-const? Because the essence of move is actually stealing resources.

[00:00:50]After the move, the source object is usually modified. Its internal resources are transferred away. For example, pointers might be set to null, lengths might become zero. But now, look at this function again. It returns a const temporary object. And a const object cannot bind to a non-const rvalue reference. What happens as a result? The move constructor may become effectively unavailable. So, the compiler falls back to using copy. In other words, you thought you were writing safer code, but you've quietly disabled move optimization. The code ends up slower.

[00:01:20]Therefore, in modern C++, it's generally not recommended to return const value.

[00:01:24]Because one of the core ideas of modern C++ is not to prevent compiler optimizations. Const correctness is important. But mindlessly adding const everywhere does not equal modern C++.