Разделение данных

[_Bers]

Сообщение от Пепел Феникса

там не будет ничего лишнего.
вы забываете так же про саму string::substr, она создает новый объект.

Я ничего не забываю. Я вам привел коды, которые используют только 1 копирование, вместо двух.

Сообщение от Пепел Феникса

да лень, код должен быть удобен, а не предьявлять требование в виде out параметра(которого можно избежать)

Интересно, чем таким принципиальным отличается вариант:

std::string test; Foo(test);

от

std::string test = Foo();

Капризы программиста ценой производительности? Ну-ну.

[Пепел Феникса]

Капризы программиста ценой производительности? Ну-ну.

в том то и дело, что не ценой.
вы вынесли создание объекта из функции и лишь.(копирование осталось)

[_Bers]

Сообщение от Пепел Феникса

в том то и дело, что не ценой.
вы вынесли создание объекта из функции и лишь.(копирование осталось)

Объект "источник" и объект "приёмник" в любом случае придётся создавать. Выдергивание подстроки в любом случае придётся делать.
Через substr, или через assign.

Штука вся в том, что бы количество копирований самих символов строки свести к минимуму.

Одно обязательное копирование произойдёт при выдергивании подстроки. А остальные могут произойти только в результате запуска копирующих конструкторов.

Ну так вот, мой подход гарантирует, что никаких левых запусков копирующих конструкторов не будет. Ваш - уповает на оптимизацию самого компилятора.

Например, 2008 студия в дебаг-версии запускает 1 лишний конструктор вот на таком коде:

class test
{
public:
    test() {std::cout<<"Constructor\n";}
    test(const test& rhs) { std::cout<<"Copy Constructor\n";}
    test Get() { test tmp; return tmp; }
};

test Foo(test& r) {  return r.Get(); }

int main() {   test t1;   test t2=Foo(t1); }

В релизе он конечно, оптимизирует этот момент. Вот только стоит ли уповать на компилятор, или все таки лучше писать компиляторо-независимый код?

[Пепел Феникса]

Например, 2008 студия в дебаг-версии запускает 1 лишний конструктор вот на таком коде:

в дебаге практически вообще не делается оптимизаций, так как они могут ухучшить отладку.
а далее это идет базовая оптимизация возвращения обьекта.

просто не вижу причины выпендриваться рядом с тем же string::substr.
разработчики libstdc++ же не идиоты.

и далее, не путаем вызов конструктора копирования с вызовом конструктора, а затем оператора присваивания.

[_Bers]

Сообщение от Пепел Феникса

в дебаге практически вообще не делается оптимизаций, так как они могут ухучшить отладку.
а далее это идет базовая оптимизация возвращения обьекта.

просто не вижу причины выпендриваться рядом с тем же string::substr.
разработчики libstdc++ же не идиоты.

и далее, не путаем вызов конструктора копирования с вызовом конструктора, а затем оператора присваивания.

Не путаем.