Если принять во внимание то, что стандарт использует для стоимости, это будет точно так же дорого. В стандарте указываются затраты с точки зрения операций, выполняемых над содержащимся типом, и это число операций остается неизменным, просто каждая из них будет быстрее.
В качестве примера рассмотрим в C ++ 03 стоимость вставки элемента в середину vector<string>. Стандарт вызывает, что O(N), где N - это размер вектора, но фактическая стоимость равна O(N * M), где M - это размер строк. Причиной игнорирования M при анализе стоимости операций в контейнерах является то, что она зависит от содержимого элемента. Эта стоимость в C ++ 0x с подвижным типом будет O(N) (строки могут быть перемещены на новые позиции), но заявленная сложность будет O(N) в обоих случаях.
Для простого контрпримера, если вы считаете, что вставка в середине вектора - дорогостоящая операция в C ++ 03, и вы рассматриваете std::vector<int>, тогда вставка в середине вектора в C ++ 0x такой же дорогой, в этом случае ускорение не происходит.
Также обратите внимание, что любое потенциальное улучшение будет зависеть от того, являются ли ваши объекты подвижными (что им не нужно), и что некоторые из текущих реализаций STL уже оптимизированы аналогичным образом ( без языковой поддержки), например, реализация Dinkumware (я думаю, что именно она) имеет некоторые оптимизации, благодаря которым при увеличении std::vector<std::vector<T> > создается новое хранилище и инициализируется с помощью пустых векторов (которые не имеют выделенной памяти, поэтому стоимость минимальна), а затем swap s векторы в старой и новой выделенных областях, эффективно реализующие семантику move .