Подтвердить что ты не робот

Конструкция в возвратном заявлении

Предположим, что у нас есть класс Foo с конструктором non explicit от int. Тогда для следующих функций:

Foo makeFoo1() { return 123; }
Foo makeFoo2() { return {123}; }

Я думаю, что makeFoo1 требует, чтобы Foo copy/move ctor был доступен, и это возможно (хотя и маловероятно), что компилятор не удаляет копию и, следовательно, приводит к истинному копированию/перемещению.

Для makeFoo2, поскольку мы используем инициализацию списка копий, копирование/перемещение не может произойти.

Должен ли я действительно беспокоиться об этом и вносить аргументы в non explicit ctors в фигурные скобки, когда я могу (как в makeFoo2)? (Скажем, если я автор библиотеки и ожидаю, что библиотека будет использоваться с подпарами-компиляторами для встроенной системы.)

4b9b3361

Ответ 1

Я выйду на конечность и сочетаю практический ответ со слабым юридическим обоснованием.

Слабый аргумент юриста-юриста: если я правильно понимаю это описание cppreference.com, вам не гарантируется RVO при инициализации с помощью списка инициализаторов (makeFoo2) больше, чем с вашим возвратом int (makeFoo1). Таким образом, не окружайте ваш int в фигурных скобках.

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

Практический аргумент 2: Принцип наименьшего удивления. Используя эти фигурные скобки, вы подразумеваете, что что-то не так с формой без брекетов. Я был бы смущен и немного удивлен фигурными скобками (хотя и не очень смущен).

Практический аргумент 3: В таких ситуациях - доверять компилятору. Это не то место, где ваше узкое место производительности (и если оно есть - сделайте его встроенной функцией, а оно не будет, или используйте ссылку, если у вас есть существующий объект и т.д.).