Предположим, что у нас есть класс Foo
с конструктором non explicit
от int
. Тогда для следующих функций:
Foo makeFoo1() { return 123; }
Foo makeFoo2() { return {123}; }
Я думаю, что makeFoo1
требует, чтобы Foo
copy/move ctor был доступен, и это возможно (хотя и маловероятно), что компилятор не удаляет копию и, следовательно, приводит к истинному копированию/перемещению.
Для makeFoo2
, поскольку мы используем инициализацию списка копий, копирование/перемещение не может произойти.
Должен ли я действительно беспокоиться об этом и вносить аргументы в non explicit
ctors в фигурные скобки, когда я могу (как в makeFoo2
)? (Скажем, если я автор библиотеки и ожидаю, что библиотека будет использоваться с подпарами-компиляторами для встроенной системы.)
Ответ 1
Я выйду на конечность и сочетаю практический ответ со слабым юридическим обоснованием.
Слабый аргумент юриста-юриста: если я правильно понимаю это описание cppreference.com, вам не гарантируется RVO при инициализации с помощью списка инициализаторов (makeFoo2
) больше, чем с вашим возвратом int (makeFoo1
). Таким образом, не окружайте ваш int в фигурных скобках.
Практический аргумент 1: Приходите один, эти фигурные скобки должны быть излишними. Они должны быть излишними. Поэтому не используйте их, это не кажется правильным.
Практический аргумент 2: Принцип наименьшего удивления. Используя эти фигурные скобки, вы подразумеваете, что что-то не так с формой без брекетов. Я был бы смущен и немного удивлен фигурными скобками (хотя и не очень смущен).
Практический аргумент 3: В таких ситуациях - доверять компилятору. Это не то место, где ваше узкое место производительности (и если оно есть - сделайте его встроенной функцией, а оно не будет, или используйте ссылку, если у вас есть существующий объект и т.д.).