Стили синтаксиса приведения C++

Лучше всего никогда не использовать приведение типов в стиле C по трем основным причинам:

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

Как отмечает palm3D:

Я нахожу синтаксис приведения в стиле C++ слишком многословным.

Это сделано намеренно по причинам, указанным выше.

Синтаксис конструктора (официальное название: приведение в стиле функции) семантически то же самое, что и приведение в стиле C, и его также следует избегать (за исключением инициализации переменных при объявлении) по тем же причинам. Можно спорить, должно ли это быть верным даже для типов, которые определяют пользовательские конструкторы, но Мейерс утверждает, что в Effective 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++ многословно, но это то, что мне в них нравится: их очень легко обнаружить, и они облегчают чтение кода (что более важно, чем написание).

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

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

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

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

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

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

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

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

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

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