Функциональный стиль шрифта возврата
Я учусь c++0x, по крайней мере, части поддерживаются Бетой Экспресса Visual C++ 2010 года. Это - вопрос о стиле, а не как он работает. Возможно, слишком рано для стиля и хорошей практики для развития все же для стандарта, который еще даже не выпущен...
В c++0x можно определить тип возврата использования метода-> тип в конце функции вместо того, чтобы поместить тип в запуск. Я полагаю, что это изменение в синтаксисе требуется из-за лямбд и некоторых вариантов использования нового 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;
}
Мой вопрос действительно затем, то, учитывая, что некоторые функции должны будут быть определены новым способом, это, полагал, что хороший стиль определил все функции таким образом для непротиворечивости? Или я должен придерживаться только использования его когда необходимый?
7 ответов
Не придерживайтесь стиля только для того, чтобы быть последовательным. Код должен быть читабельным, то есть понятным, это единственная реальная мера. Добавление беспорядка к 95% методов, чтобы они соответствовали остальным 5%, ну, это просто не кажется мне правильным.
Мне кажется, это изменит жизненную привычку многих программистов на C ++ (и других подобных).
Если вы использовали этот стиль для каждой отдельной функции, то, возможно, вы единственный, кто это делал: -)
Я собираюсь предположить, что текущий стандарт победит, как и все другие предлагаемые изменения определения. Конечно, он был расширен, но основная семантика C ++ настолько интегрирована, что я не думаю, что ее стоит менять. Они повлияли на очень много языков и руководств по стилю, это просто смешно.
Что касается вашего вопроса, я бы попытался разделить код на модули, чтобы было понятно, где вы используете старый стиль или новый стиль. Там, где эти два смешиваются, я бы постарался максимально точно их очертить. Сгруппируйте их вместе и т. Д.
[личное мнение] Мне очень неприятно просматривать файлы и наблюдать, как стиль меняется взад и вперед или радикально меняется. Это просто заставляет меня задуматься, что еще там скрывается [/ личное мнение]
Я не считаю необходимым использовать его для обычных функций. У него есть особые возможности, позволяющие легко делать то, что раньше могло показаться довольно неудобным. Например:
template <class Container, class T>
auto find(Container& c, const T& t) -> decltype(c.begin());
Здесь мы не знаем, является ли Контейнер константным или нет, следовательно, будет ли возвращаемый тип Контейнер :: итератор или Контейнер :: const_iterator (может быть определяется из того, что вернет begin () ).
Существует огромная кодовая база, которая использует «старые» / текущие правила.Могу поспорить, что так будет надолго. Проблема согласованности двоякая: с кем вы собираетесь быть последовательными, с тем немногим кодом, который потребует новый синтаксис или весь существующий код?
Я буду придерживаться старого синтаксиса, когда новый не требуется для немного, но опять же, только время покажет, что станет обычным использованием.
Также обратите внимание, что новый синтаксис все еще немного странный: вы объявляете возвращаемый тип как auto , а затем определяете, что означает auto , в конце объявления подписи ... Это не кажется естественным (даже если вы не сравниваете это со своим собственным опытом)
Лично я бы использовал его, когда это необходимо. Как и , это -> необходимо только при доступе к элементам шаблона базового класса (или когда они иным образом скрыты), поэтому auto fn () -> type необходим только тогда, когда Тип возвращаемого значения не может быть определен до того, как будет видна остальная часть сигнатуры функции.
Использование этого практического правила, вероятно, поможет большинству читателей кода, которые могут подумать: «Почему автор решил, что нам нужно писать декларацию таким образом?» иначе.
Хорошие изменения стиля - если вы мне не верите, посмотрите, что было хорошим стилем в 98 году, а что сейчас - и это трудно знать, что будет считаться хорошим стилем и почему. IMHO, в настоящее время все, что связано с C ++ 0X, является экспериментальным, и квалификация хороший или плохой стиль еще не применяется.