Challenge 2: Reading a Moved-From std::string — Possible Solution ==================================================================== #include #include int main() { std::string original = "Hello, world!"; std::string moved_to = std::move(original); std::cout << "moved_to: " << moved_to << std::endl; std::cout << "original: " << original << std::endl; return 0; } Typical output (the exact second line is not guaranteed by the standard): moved_to: Hello, world! original: Explanation: moved_to correctly received the string's content, since std::move selected std::string's own move constructor/assignment, transferring its internal buffer efficiently. original, however, is now in std::string's own "valid but unspecified" moved-from state -- in practice, libstdc++/libc++ typically leave it as an empty string (as shown above), but the C++ standard does NOT guarantee this exact result; a different standard library implementation could leave it in some other valid-but-different state. Why this is a logic bug rather than undefined behavior: per the chapter, a moved-from object remains genuinely SAFE to use in a limited way -- it's still a valid, well-formed std::string object, safe to destroy or reassign a new value to. Reading its CONTENT for any purpose beyond that, as this program does, isn't memory-unsafe or UB-triggering the way c1-7's dangling pointer would be -- it simply reads a real, valid string whose actual content the program has no right to assume anything specific about. The mistake is purely at the LOGIC level (assuming original still held "Hello, world!"), not a memory-safety violation. WHY THIS WORKS AS AN ANSWER ------------------------------ This shows a realistic (though not standard-guaranteed) output, explicitly flags that the specific empty-string result is an implementation detail rather than a guarantee, and correctly distinguishes the logic-bug classification (reading unspecified but still valid, memory-safe content) from undefined behavior, exactly the precise distinction the chapter draws.