Author here! My "example" is showing an equivalent to what the C++ compiler actually outputs, inlining the `std::string` abstraction, given the input code, whi

Author here! My "example" is showing an equivalent to what the C++ compiler actually outputs, inlining the `std::string` abstraction, given the input code, which in this context was C++03, and before emplace. But emplace doesn't save you here! Emplace doesn't save on heap allocations over a `strdup`, if you're emplacing something from a string literal like this. Doing: ``` vec.emplace_back("here's a string"); ``` Does indeed do an allocation for the string. It has to, because every `std::string` must manage a heap allocation (modulo the small string optimization which is a nitpick). The string literal is in the `text` section of the binary and can't be the backing for the `std::string` object, which must be in read-write memory and on the heap. So the `strdup` is correct as an equivalent to what the C++ compiler would output with `std::string` inlined for the example code it covered. Also, the freeing of the empty object with move semantics is NOT always optimized out, not even close. It can't be, not when those calls can cross a library boundary or be arbitrarily wonky. You write as if C++ has one optimizer. Rust shares an optimizer with one of the most popular C++ compilers. Implying Rust is somehow "behind" C++ on optimizations is just ill-informed.