Синтаксические стили C ++

Question

Вопрос, связанный с Обычное приведение против static_cast против dynamic_cast :

Какой стиль синтаксиса вы предпочитаете в C ++?

• Синтаксис в стиле C: (int)foo
• C ++ - стиль синтаксиса приведения: static_cast<int>(foo)
• синтаксис конструктора: int(foo)

Они могут не переводить точно такие же инструкции (не так ли?), Но их эффект должен быть одинаковым (верно?).

Если вы просто выполняете приведение между встроенными числовыми типами, я нахожу синтаксис преобразования в стиле C ++ слишком подробным. Как бывший Java-кодер, я склонен использовать вместо этого синтаксис в стиле C, но мой местный гуру C ++ настаивает на использовании синтаксиса конструктора.

Что вы думаете?

Answer 1

Лучше всего никогда использовать броски в стиле 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.

Answer 2

По Страуструпу :

Были введены "броски в новом стиле" дать программистам возможность заявить их намерения более четко и компилятор, чтобы ловить больше ошибок.

На самом деле, это для безопасности, так как он выполняет дополнительную проверку во время компиляции.

Answer 3

По этому вопросу я следую рекомендациям, сделанным Скоттом Мейерсом ( Более эффективный C ++ , пункт 2: Предпочитает приведение в стиле C ++).

Я согласен с тем, что приведение в стиле C ++ является многословным, но это то, что мне нравится в них: их очень легко обнаружить, и они облегчают чтение кода (что важнее, чем написание).

Они также заставляют вас задуматься о том, какой тип каста вам нужен, и выбрать правильный, снижая риск ошибок. Они также помогут вам обнаружить ошибки во время компиляции, а не во время выполнения.

Answer 4

Определенно C ++ - стиль. Дополнительный набор текста поможет вам избежать каста, если вы не должны: -)

Answer 5

Я использую static_cast по двум причинам.

1. Ясно ясно, что происходит. Я не могу перечитать это, не осознавая, что происходит актерский состав. С приведениями в стиле C ваш глаз может пройти прямо через него без паузы.
2. В моем коде легко найти каждое место, где я веду каст.

Answer 6

Синтаксис конструктора. C ++ - ОО, конструкторы существуют, я их использую. Если вы чувствуете необходимость аннотировать эти преобразователи, вы должны делать это для каждого типа, а не только для встроенных. Может быть, вы используете ключевое слово «явное» для преобразования кодоров, но синтаксис клиента имитирует именно то, что делает синтаксис ctor для встроенных типов. Возможно, это правда, но удивительно, что ввод большего количества символов облегчает поиск. Зачем относиться к этим как к особенным? Если вы пишете математические формулы с большим количеством int / unsigned / ... для и из double / float - graphics - и вам нужно каждый раз писать static_cast, внешний вид формулы становится загроможденным и очень нечитаемым. И в любом случае это тяжелая битва, так как много раз вы обращаетесь, даже не замечая, что вы есть. Для указателей с понижением частоты я использую static_cast, поскольку, конечно, по умолчанию не существует ctor, который бы это делал.

Answer 7

Перейти к стилю C ++ и, что еще хуже, уродливые подробные фрагменты кода, которые включали явную типизацию C ++, будут постоянным напоминанием о том, что мы все знаем (то есть явное приведение плохо - ведет к монетизации ругательств) , Не используйте стиль C ++, если вы хотите овладеть искусством отслеживания ошибок во время выполнения.

Answer 8

В настоящее время мы используем повсеместное приведение в стиле C. Я задал другой вопрос о кастинге , и теперь я вижу преимущество использования static_cast вместо этого, если только по какой-то другой причине, кроме "greppable" (мне нравится этот термин). Я, вероятно, начну использовать это.

Мне не нравится стиль C ++; это выглядит слишком похоже на вызов функции.

Answer 9

Применение в стиле C - худший путь. Его труднее увидеть, не заметить, объединить различные действия, которые не следует смешивать, и не может сделать все, что могут делать приведения в стиле C ++. Они действительно должны были убрать приведение в стиле C из языка.

Answer 10

Синтаксис в стиле C, проверка ошибок не производится. C ++ - стиль синтаксиса приведения, выполняет некоторую проверку. При использовании static_cast, даже если он не выполняет проверку, по крайней мере, вы знаете, что вам следует быть здесь осторожным.