На встрече по стандартам ISO C ++ в Оулу в 2016 г. было внесено предложение под названием Гарантированное копирование с помощью упрощенных категорий значений было одобрено комитетом по стандартам C ++ 17.
Как именно работает гарантированное копирование? Охватывает ли он некоторые случаи, когда исключение копирования уже было разрешено, или необходимы ли изменения кода, чтобы гарантировать исключение копирования?
Копирование разрешалось при ряде обстоятельств. Однако, даже если это было разрешено, код все равно должен был работать так, как если бы копия не была опущена. А именно, должен быть доступный конструктор копирования и / или перемещения.
Гарантированное исключение копирования переопределяет ряд концепций C ++, так что определенные обстоятельства, при которых копии / перемещения могут быть исключены, фактически не вызывают копирование / перемещение вообще. Компилятор не исключает копию; в стандарте сказано, что такого копирования никогда не может быть.
Рассмотрим эту функцию:
T Func() {return T();}
Согласно правилам негарантированной копии, это создаст временное, а затем перейдет из этого временного в возвращаемое значение функции. Эту операцию перемещения можно пропустить, но T по-прежнему должен иметь доступный конструктор перемещения, даже если он никогда не используется.
Сходным образом:
T t = Func();
Это инициализация копии t. Это скопирует инициализацию t с возвращаемым значением Func. Однако T по-прежнему должен иметь конструктор перемещения, даже если он не будет вызываться.
Гарантированное исключение копирования переопределяет значение выражения prvalue. До C ++ 17 prvalue были временными объектами. В C ++ 17 выражение prvalue - это просто то, что может материализовать временное, но это еще не временное явление.
Если вы используете prvalue для инициализации объекта типа prvalue, временное значение не материализуется. Когда вы выполняете return T();, это инициализирует возвращаемое значение функции через prvalue. Поскольку эта функция возвращает T, временные данные не создаются; инициализация prvalue просто напрямую инициирует возвращаемое значение.
Следует понимать, что, поскольку возвращаемое значение является значением prvalue, это еще не объект. Это просто инициализатор объекта, как и T().
Когда вы делаете T t = Func();, prvalue возвращаемого значения напрямую инициализирует объект t; отсутствует этап «создание временного и копирование / перемещение». Поскольку возвращаемое значение Func() является prvalue, эквивалентным T(), t напрямую инициализируется T(), точно так же, как если бы вы сделали T t = T().
Если prvalue используется каким-либо другим образом, prvalue материализует временный объект, который будет использоваться в этом выражении (или отброшен, если выражение отсутствует). Итак, если вы сделали const T &rt = Func();, значение prvalue материализовалось бы как временное (используя T() в качестве инициализатора), ссылка на который будет храниться в rt вместе с обычным временным материалом для продления срока службы.
Одна вещь, которую вам разрешает гарантированная элизия, - это возвращать неподвижные объекты. Например, lock_guard нельзя скопировать или переместить, поэтому у вас не может быть функции, возвращающей его по значению. Но с гарантированным копированием вы можете.
Гарантированное исключение также работает с прямой инициализацией:
new T(FactoryFunction());
Если FactoryFunction возвращает T по значению, это выражение не копирует возвращаемое значение в выделенную память. Вместо этого он будет выделять память и использовать выделенную память в качестве памяти возвращаемых значений для прямого вызова функции.
Таким образом, фабричные функции, которые возвращаются по значению, могут напрямую инициализировать память, выделенную кучей, даже не подозревая об этом. Конечно, пока эти функции внутри следуют правилам гарантированного исключения копий. Они должны вернуть значение типа T.
Конечно, это тоже работает:
new auto(FactoryFunction());
Если вам не нравится писать имена типов.
Важно понимать, что вышеуказанные гарантии работают только для prvalues. То есть вы не получаете никакой гарантии при возврате именованной переменной:
T Func()
{
T t = ...;
...
return t;
}
В этом случае t все еще должен иметь доступный конструктор копирования / перемещения. Да, компилятор может выбрать оптимизацию копирования / перемещения. Но компилятор по-прежнему должен проверять наличие доступного конструктора копирования / перемещения.
Таким образом, для оптимизации именованного возвращаемого значения (NRVO) ничего не меняется.
std::chrono есть некоторые из этих типов). Или, может быть, возврат в регистр все еще в порядке, если тип тривиально копируемый, так что определение того, произошло ли исключение, невозможно?
- person Ben Voigt; 27.06.2016
main позвонил b, а не a. Но ответ в любом случае один и тот же: он не материализует никаких временных. вы говорите, что A () материализуется в возвращаемом объекте a () Нет, я этого не делал. Я сказал, это инициализирует возвращаемый объект функции через prvalue. Это не то же самое, что материализовать временное. По сути, A() prvalue инициализирует возвращаемое значение a, которое инициализирует возвращаемое значение b, которое инициализирует объект c. Таким образом, по транзитивному свойству A() инициализирует c.
- person Nicol Bolas; 24.05.2017
T var = Func(), если Func возвращает t; (т.е. именованный автоматический), я думаю, что var инициализируется t, сначала путем обработки t как rvalue (и т. Д. По обычным правилам). Так что в некотором смысле здесь задействовано и гарантированное исключение копирования. Но также может применяться обычное исключение копирования, которое может полностью опустить локальный объект функции t и свернуть его в var.
- person Johannes Schaub - litb; 27.05.2017
constexpr механизме, о котором вы говорите.
- person Nicol Bolas; 27.05.2017
std::function<T()> на самом деле.
- person Yakk - Adam Nevraumont; 30.05.2017
initializer expression несколько раз (например, 8.5 Bullet 17.6), но что такое initializer expression. Я не мог найти ему определения.
- person doraemon; 31.07.2018
A x = instanceA + returnsA() + returnsRefToA() + returnsRRefToA()? returnsA() - это prvalue, которое материализуется как операнд для +, returnsRefToA() - это lvalue; а returnsRRefToA() - значение x. Но все они используются для инициализации параметра для operator +, должны ли они быть prvalue? Или они glvalue конвертируются в prvalue автоматически?
- person doraemon; 01.08.2018
T t = Func(); вы говорите: Это инициализация копии t. Это скопирует инициализацию t с возвращаемым значением Func. Однако у T по-прежнему должен быть конструктор перемещения, даже если он не будет вызываться ... Я не понимаю, как это правда. Разве Func() не является значением prvalue или xvalue и, следовательно, будет вызываться возможно существующий конструктор перемещения? Например, в: coliru.stacked-crooked.com/a/f3339b1c6604b928
- person user1658887; 11.01.2019
T t{}; с T t;.
- person Nicol Bolas; 29.09.2020
Думаю, здесь подробно рассказали о копировании. Однако я нашел эту статью: https://jonasdevlieghere.com/guaranteed-copy-elision который относится к гарантированному исключению копирования в C ++ 17 в случае оптимизации возвращаемого значения.
Это также относится к тому, как, используя параметр gcc: -fno-elide-constructors, можно отключить исключение копирования и увидеть, что вместо конструктора, вызываемого напрямую в месте назначения, мы видим 2 конструктора копирования (или конструкторы перемещения в С ++ 11 ) и вызываемые им соответствующие деструкторы. В следующем примере показаны оба случая:
#include <iostream>
using namespace std;
class Foo {
public:
Foo() {cout << "Foo constructed" << endl; }
Foo(const Foo& foo) {cout << "Foo copy constructed" << endl;}
Foo(const Foo&& foo) {cout << "Foo move constructed" << endl;}
~Foo() {cout << "Foo destructed" << endl;}
};
Foo fReturnValueOptimization() {
cout << "Running: fReturnValueOptimization" << endl;
return Foo();
}
Foo fNamedReturnValueOptimization() {
cout << "Running: fNamedReturnValueOptimization" << endl;
Foo foo;
return foo;
}
int main() {
Foo foo1 = fReturnValueOptimization();
Foo foo2 = fNamedReturnValueOptimization();
}
vinegupt@bhoscl88-04(~/progs/cc/src)$ g++ -std=c++11 testFooCopyElision.cxx # Copy elision enabled by default
vinegupt@bhoscl88-04(~/progs/cc/src)$ ./a.out
Running: fReturnValueOptimization
Foo constructed
Running: fNamedReturnValueOptimization
Foo constructed
Foo destructed
Foo destructed
vinegupt@bhoscl88-04(~/progs/cc/src)$ g++ -std=c++11 -fno-elide-constructors testFooCopyElision.cxx # Copy elision disabled
vinegupt@bhoscl88-04(~/progs/cc/src)$ ./a.out
Running: fReturnValueOptimization
Foo constructed
Foo move constructed
Foo destructed
Foo move constructed
Foo destructed
Running: fNamedReturnValueOptimization
Foo constructed
Foo move constructed
Foo destructed
Foo move constructed
Foo destructed
Foo destructed
Foo destructed
Я вижу оптимизацию возвращаемого значения. исключение копирования временных объектов в операторах возврата, как правило, гарантируется независимо от C ++ 17.
Тем не менее, именованная оптимизация возвращаемого значения возвращаемых локальных переменных происходит в большинстве случаев, но не гарантируется. В функции с разными операторами возврата я вижу, что если каждый из операторов возврата возвращает переменные локальной области видимости или переменные той же области видимости, это произойдет. В противном случае, если в разных операторах возврата возвращаются переменные с разными областями видимости, компилятору будет сложно выполнить копирование.
Было бы неплохо, если бы был способ гарантировать исключение копирования или получить какое-то предупреждение, когда удаление копирования не может быть выполнено, что заставило бы разработчиков убедиться, что выполняется исключение копирования, и повторно использовать код, если он не может быть выполнен .
