Я не уверен, как компилятор будет оптимизировать копию (если вообще) без std::move().

только a очень умный компилятор может оптимизировать это, поэтому, если копия может быть дорогой (например, очень длинная строка), то лучше ее переместить.

без перемещения в код фактически представляет собой последовательность вызовов:

strlen  // count "Hello World"
malloc  // allocate memory for string var
strcpy  // copy data into var
malloc  // re-allocate vector
free    // deallocate old vector
malloc  // allocate new string
strcpy  // copy from var to new string
free    // destroy var

С ходом он становится:

strlen  // count "Hello World"
malloc  // allocate memory for string var
strcpy  // copy data into var
malloc  // re-allocate vector
free    // deallocate old vector

теоретически умный компилятор может сделайте это преобразование автоматически, но для компилятора, чтобы увидеть через все слои абстракции, введенные конструкторами и деструктором и vector функции-члены довольно сложно, поэтому доказать, что код может быть преобразован для удаления malloc и free сложная.

после std::move исходный объект, в данном случае var, должно быть в допустимом состоянии, но может содержать любое значение, например, оно может быть пустым.

если вы знаете, что вы не собираетесь использовать var и вы только создали его, чтобы положить в vector тогда это не совсем "преждевременная" оптимизация, как намерение того, что вы пытаетесь сделать.

vector новый способ emplace_back() что то же самое, но яснее, и использует forward-аргументы (здесь вы просто делаете emplace_back("Hello World") если все, что вы делаете при его строительстве). В вашем случае, как вы "делаете некоторые изменения с var"emplace_back вряд ли будет неуместно.

старый C++ вы можете оптимизировать копию, сделав push_back() на пустую строку, а затем замена его.

Я не знаю, почему все предлагают вам использовать emplace_back(). Цель emplace_back() чтобы избежать операций копирования/перемещения по строительству объекта на месте. В этом случае, вы уже построили объект, так, по крайней мере, 1 копирование/перемещение неизбежно. Нет никакого преимущества в использовании emplace_back() over push_back() в этом случае.

в противном случае я согласен со всеми остальными, говоря, что это не преждевременная оптимизация, потому что семантика перемещения моделирует то, что вы пытаетесь сделать более тесно чем делать копию объекта.

Да, это преждевременная оптимизация, если это преждевременная оптимизация.

Позвольте уточнить:
Преждевременная оптимизация определяется тем, оптимизируете ли вы часть кода, которая не является критически важной для производительности. То есть преждевременная оптимизация никогда не определяется методом оптимизации, она всегда определяется местом оптимизации и вашими знаниями о том, что вы делаете.

---

теперь о целесообразности оптимизации используя std::move():

С std::move() вам избежать тяжелого подъема строительных копию, как выделение памяти, освобождение памяти, копию построения элементов, разрушение элементов, и т. д. Это хорошо. Но одна часть повторяется: строительство/разрушение объекта контейнера.

emplace_back() имеет преимущество полностью избежать строительства временного объекта. Таким образом, всякий раз, когда вы можете избежать временного объекта с помощью emplace_back(), у вас есть небольшой выиграть.

учитывая качество кода (читаемость/ремонтопригодность):std::move() имеет обратную сторону, оставляя вас с непригодным объектом, который может быть источником ошибок. Это не происходит с emplace_back(). Так что, опять же, последнее явно предпочтительнее.

конечно, emplace_back() не может использоваться во всех контекстах, которые позволяют использовать std::move(). Итак, если это критическая производительность,std::move() может быть, так и надо. Есть несколько очень допустимых вариантов использования для оптимизации с помощью std::move(). Тем не менее, вы также можете узнать, что вы можете написать код таким образом, что не требует никакого копирования/перемещения/emplace конструкции вообще. Никогда не прекращайте искать лучшее решение при оптимизации!

в конце концов, остается, что обоснованность оптимизации с std::move() полностью зависит от контекста: это хорошая оптимизация, где это хорошая оптимизация.