Что-то не так с возвратом значений по умолчанию?

Question

Предположим, у меня есть следующий код:

class some_class{};

some_class some_function()
{
    return some_class();
}

Это, кажется, работает довольно хорошо и избавляет меня от необходимости объявлять переменную только для того, чтобы получить возвращаемое значение Но я не думаю, что когда-либо видел это в каком-либо учебнике или справочнике. Это специфичная для компилятора вещь (визуальный C ++)? Или это что-то делает не так?

Answer 1

Нет, это совершенно верно. Это также будет более эффективным, так как компилятор действительно способен оптимизировать временное.

Answer 2

Возврат объектов из вызова функции - это шаблон проектирования «Фабрика», который широко используется.

Однако вам нужно быть осторожным, возвращаете ли вы объекты или указатели на объекты. Первый из них познакомит вас с копированием конструкторов / операторов присваивания, что может быть неприятно.

Answer 3

Разница между примером Роба Уокера называется Оптимизация возвращаемого значения (RVO), если вы хотите найти его в Google.

Кстати, если вы хотите, чтобы ваш объект возвращался наиболее эффективным способом, создайте объект в куче (т.е. через new), используя shared_ptr, и вместо этого верните shared_ptr. Указатель возвращается и ссылка считается правильно.

Answer 4

Это допустимо, но производительность может быть не идеальной, в зависимости от того, как она называется.

Например:

A a;
a = fn();

и

A a = fn();

не совпадают.

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

Во втором случае используется конструктор копирования.

Достаточно умный компилятор определит, какие оптимизации возможны. Но если конструктор копирования предоставлен пользователем, я не вижу, как компилятор может оптимизировать временную переменную. Он должен вызывать конструктор копирования и для этого должен иметь другой экземпляр.

Answer 5

Это лучший способ сделать это, если ваш класс довольно легкий - я имею в виду, что сделать его копию не очень дорого.

Одним из побочных эффектов этого метода является то, что он, как правило, повышает вероятность создания временных объектов, хотя это может зависеть от того, насколько хорошо компилятор может оптимизировать вещи.

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

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

Answer 6

Это совершенно законный C ++, и любой компилятор должен его принять. С чего вы взяли, что он может что-то делать не так?

Answer 7

Это вполне разумно, C ++.