Стиль возврата типа функции

Question

Я изучаю c++0x, по крайней мере части, поддерживаемые Visual C ++ Express 2010 Beta. Это вопрос о стиле, а не о том, как он работает. Возможно, еще слишком рано, чтобы стиль и хорошая практика развивались для стандарта, который еще даже не выпущен ...

В c++0x вы можете определить тип возвращаемого значения метода, используя -> type в конце функции вместо того, чтобы помещать тип в начало. Я считаю, что это изменение в синтаксисе необходимо из-за лямбда-выражения и некоторых случаев использования нового ключевого слова decltype, но, насколько я знаю, его можно использовать где угодно.

// Old style 
int add1(int a, int b)
{
 return a + b;
}

// New style return type
auto add2(int a, int b) -> int
{
 return a + b;
}

Тогда мой вопрос действительно заключается в том, что некоторые функции необходимо определить по-новому. Считается ли это хорошим стилем для определения всех функций таким образом для согласованности? Или я должен использовать его только при необходимости?

Answer 1

Не будьте последовательными по стилю только за то, что последовательны. Код должен быть читаемым, то есть понятным, это единственная реальная мера. Добавление беспорядка в 95% методов, чтобы соответствовать другим 5%, ну, это просто не подходит мне.

Answer 2

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

template <class Container, class T>
auto find(Container& c, const T& t) -> decltype(c.begin());

Здесь мы не знаем, является ли контейнер постоянным или нет, следовательно, будет ли тип возвращаемого значения Container::iterator или Container::const_iterator (может быть определено из того, что begin() вернет).

Answer 3

Лично я бы использовал его, когда это необходимо. Точно так же, как this-> необходим только при доступе к членам шаблона базового класса (или когда они скрыты), так что auto fn() -> type необходим только тогда, когда тип возвращаемого значения не может быть определен до того, как остальная часть сигнатуры функции станет видимой .

Использование этого эмпирического правила, вероятно, поможет большинству читателей кода, которые могут подумать: «Почему автор решил, что нам нужно написать декларацию таким образом?» в противном случае.

Answer 4

Существует огромная кодовая база, которая использует «старые» / текущие правила. Могу поспорить, что так будет долго. Проблема согласованности двояка: с кем вы будете согласны, несколько кодов, для которых потребуется новый синтаксис, или весь существующий код?

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

Также обратите внимание, что новый синтаксис все еще немного странен: вы объявляете тип возвращаемого значения как auto и затем определяете, что означает auto в конце объявления подписи ... Это не кажется естественным (даже если Вы не сравниваете это с собственным опытом)

Answer 5

Я собираюсь догадаться, что текущий стандарт победит, как это было до сих пор со всеми другими предлагаемыми изменениями в определении. Конечно, она была расширена, но основная семантика C ++ настолько детальна, что я не думаю, что ее стоит менять. Они повлияли на очень многие языки, и стиль делает его смешным.

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

[личное мнение] Мне действительно неприятно просматривать файлы и смотреть, как стиль меняется вперед или назад или радикально меняется. Это просто заставляет меня задуматься, что еще там скрывается [/ личное мнение]

Answer 6

Мне кажется, что это изменит привычку всей жизни многих программистов на C ++ (и других подобных).

Если вы использовали этот стиль для каждой отдельной функции, то, возможно, вы будете единственным, кто делает это: -)

Answer 7

Хорошие изменения стиля - если вы не верите мне, посмотрите, что было хорошим стилем в 98 году, а что сейчас - и трудно понять, что будет считаться хорошим стилем и почему. ИМХО, в настоящее время все, что связано с C ++ 0X, является экспериментальным, а квалификация «хороший» или «плохой» - пока не применима.