Какой идиоматический способ документировать static_cast?

Первые два, (MyType)foo и MyType(foo), имеют одинаковое значение. Значение во многом зависит от MyType и типа foo. Так например:

((int)1.0);   // a static_cast
int i = 0;
((char*)&i);  // a reinterpret_cast
const int j = 0;
((int*)&j);   // a const_cast
((char*)&j);  // a combination of a const_cast and a reinterpret_cast

typedef char *CharPtr;
CharPtr(&j);  // a C-style cast, same as ((CharPtr)&j) or ((char*)&j)

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

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

Приведения в функциональном стиле с одним аргументом являются приведениями в стиле C. Они явно определены в стандарте и означают одно и то же во всех случаях.

Теперь есть некоторые случаи, когда вы можете принять приведение в стиле C, когда оно написано с использованием функционального синтаксиса, но не при написании с синтаксисом преобразования C. Обычно это происходит, когда тип назначения является классом и очевидно, какой конструктор будет вызван. В таком случае std::vector<int>(0) короче static_cast<std::vector<int>>(0) и в целом более понятен, поскольку его можно прочитать как вызов конструктора. Но в нем все еще есть те же «опасности», что и в письме (std::vector<int>)0. Если бы вы так записывали каждое преобразование, то в конечном итоге вы случайно удалили бы const из типа указателя.

В моей книге использование явного приведения является идиоматическим.

static_cast<MyType>(foo) лучше, чем (MyType)foo, потому что он более выразительный и ясный. Это особенно полезно во многих случаях, когда (MyType)foo не означает то, что вы ожидаете. Например, в ваших примерах эти случаи могут вообще не уменьшаться до static_cast, а до reinterpret_cast.

При обзоре кода я бы отверг все без исключения приведения в стиле C к неарифметическим типам.

Во-первых, приведения функциональных стилей являются новыми приведениями в стиле C ++. Они делают то же самое.

Приведение в стиле C сначала пытается static_cast, а если это не помогает, выполняет reinterpret_cast ¹. Это плохо, потому что операции, предназначенные для простого изменения, могут стать очень странными.

В качестве примера предположим, что у вас есть Foo* f и совершенно не связанный класс Bar. Вы можете (Bar*)f, и он будет молча переинтерпретировать *f как Bar, что, вероятно, приведет к неопределенному поведению.

static_cast будет работать в этой ситуации, только если Foo и Bar относятся к родственным типам.

Теперь даже static_cast может быть слишком сильным, поэтому я часто пишу шаблон implicit_cast или non_cast, который преобразует без преобразования. Точно так же я пишу as_const, который добавляет const, вместо того, чтобы требовать const_cast (который может как добавлять, так и удалять const, а удаление const намного опаснее, чем его добавление).

Несколько раздражает то, что в C ++ нет явного безопасного преобразования типов, и я не знаю, как его написать (такой, который будет выполнять explicit конструкторы, но не будет приводить "вниз" иерархию типов, как static_cast будет).

¹ это чрезмерное упрощение, но достаточно близкое к истине.