Синтаксические стили C++
Вопрос, связанный с обычным приведением против static_cast и dynamic_cast:
Какой стиль синтаксиса приведения вы предпочитаете в C++?
- Синтаксис в стиле C:
(int)foo - C++ - стиль синтаксиса приведения:
static_cast<int>(foo) - синтаксис конструктора:
int(foo)
Они могут не переводить в точности одинаковые инструкции (не так ли?), Но их эффект должен быть одинаковым (верно?).
Если вы просто выполняете приведение между встроенными числовыми типами, я нахожу синтаксис преобразования в стиле C++ слишком многословным. Как бывший Java-кодер, я склонен использовать вместо этого синтаксис в стиле C, но мой местный гуру C++ настаивает на использовании синтаксиса конструктора.
Как вы думаете?
10 ответов
Лучше не использовать броски в стиле C по трем основным причинам:
- как уже упоминалось, здесь не выполняется проверка. Программист просто не может знать, какое из различных приведений используется, что ослабляет строгую типизацию
- новые броски преднамеренно визуально поразительны. Поскольку приведения часто выявляют слабые места в коде, утверждается, что делать приведения видимыми в коде - это хорошо.
- это особенно актуально, если поиск выполняется с помощью автоматизированного инструмента. Надежно найти слепки в стиле C практически невозможно.
Как отмечает palm3D:
Я нахожу синтаксис в стиле C++ слишком многословным.
Это сделано намеренно по причинам, указанным выше.
Синтаксис конструктора (официальное имя: приведение в стиле функции) семантически совпадает с приведением в стиле C, и его также следует избегать (за исключением инициализации переменных при объявлении) по тем же причинам. Это спорно, должно ли это быть правда, даже для типов, которые определяют пользовательские конструктор, но в эффективном C++, Мейерс утверждает, что даже в тех случаях, следует воздержаться от их использования. Проиллюстрировать:
void f(auto_ptr<int> x);
f(static_cast<auto_ptr<int> >(new int(5))); // GOOD
f(auto_ptr<int>(new int(5)); // BAD
static_cast здесь на самом деле называют auto_ptr конструктор.
По словам Страуструпа:
Были введены "приведения в новом стиле", чтобы дать программистам возможность более четко заявить о своих намерениях, а компилятору - поймать больше ошибок.
Так что на самом деле, это для безопасности, поскольку это делает дополнительную проверку во время компиляции.
Что касается этой темы, я следую рекомендациям Скотта Мейерса ( Более эффективный C++, пункт 2: Предпочитают приведение в стиле C++).
Я согласен с тем, что приведение стиля в C++ является многословным, но это то, что мне нравится в них: их очень легко обнаружить, и они облегчают чтение кода (что важнее, чем написание).
Они также заставляют вас задуматься о том, какой актерский состав вам нужен, и выбрать правильный, снижая риск ошибок. Они также помогут вам обнаружить ошибки во время компиляции, а не во время выполнения.
Определенно стиль C++. Дополнительный набор текста поможет вам избежать каста, когда вы не должны:-)
Синтаксис конструктора. C++ - ОО, конструкторы существуют, я их использую. Если вы чувствуете необходимость аннотировать эти преобразователи, вы должны делать это для каждого типа, а не только для встроенных. Может быть, вы используете ключевое слово "явное" для преобразования кодоров, но синтаксис клиента имитирует именно то, что делает синтаксис ctor для встроенных типов. Возможно, это правда, но удивительно, что ввод большего количества символов облегчает поиск. Зачем относиться к этим как к особенным? Если вы пишете математические формулы с большим количеством int / unsigned /... для и из double / float - graphics - и вам нужно каждый раз писать static_cast, внешний вид формулы становится загроможденным и очень нечитаемым. И в любом случае это тяжелая битва, так как много раз вы обращаетесь, даже не замечая, что вы есть. Для указателей downcasting я использую static_cast, поскольку, конечно, по умолчанию не существует ctor, который бы это делал.
Я использую static_cast по двум причинам.
- Ясно ясно, что происходит. Я не могу перечитать это, не осознавая, что происходит актерский состав. С приведениями в стиле C ваш глаз может пройти прямо через него без паузы.
- В моем коде легко найти каждое место, где я веду каст.
В ролях в стиле C это худший путь. Его сложнее увидеть, не заметить, объединить различные действия, которые не следует смешивать, и не может сделать все, что могут делать приведения в стиле C++. Они действительно должны были удалить броски в стиле C из языка.
Переходите на стиль C++ и, что еще хуже, уродливые подробные фрагменты кода, которые содержали явную типизацию C++, будут постоянным напоминанием о том, что мы все знаем (т.е. явное приведение плохо - ведет к монетизации ругательств). Не используйте стиль C++, если вы хотите овладеть искусством отслеживания ошибок во время выполнения.
Синтаксис приведения в стиле C, не проверять ошибки. C++- стиль синтаксиса приведения, выполняет некоторую проверку. При использовании static_cast, даже если он не выполняет проверку, по крайней мере, вы знаете, что вы должны быть осторожны здесь.
В настоящее время мы используем повсеместное приведение в стиле C. Я задал другой вопрос о кастинге, и теперь я вижу преимущество использования static_cast вместо этого, если по какой-то другой причине, кроме как "greppable" (мне нравится этот термин). Я, вероятно, начну использовать это.
Мне не нравится стиль C++; это выглядит слишком похоже на вызов функции.