С ++ 20 bit_cast против reinterpret_cast

Что ж, есть одна очевидная причина: потому что он не будет делать все, что делает bit_cast. Даже в мире C++ 20, где мы можем выделять память во время компиляции, reinterpret_cast запрещен в функциях constexpr. Одна из явных целей bit_cast - иметь возможность делать такие вещи во время компиляции:

Furthermore, it is currently impossible to implement a constexpr bit-cast function, as memcpy itself isn’t constexpr. Marking the proposed function as constexpr doesn’t require or prevent memcpy from becoming constexpr, but requires compiler support. This leaves implementations free to use their own internal solution (e.g. LLVM has a bitcast opcode).

Теперь вы можете сказать, что можете просто расширить это конкретное использование reinterpret_cast на контексты constexpr. Но это усложняет правила. Вместо того, чтобы просто знать, что reinterpret_cast нельзя использовать в период кода constexpr, вы должны помнить конкретные формы reinterpret_cast, которые нельзя использовать.

Также есть практические проблемы. Даже если вы хотите пойти по пути reinterpret_cast, std::bit_cast - это библиотечная функция. И всегда легче получить функцию библиотеки через комитет, чем функцию языка, даже если она получит некоторую поддержку компилятора.

Тогда есть более субъективные вещи. reinterpret_cast обычно считается опасной по своей сути операцией, что свидетельствует о некотором "обмане" системы типов. Напротив, bit_cast - нет. Он создает новый объект, как будто копируя его представление значения из существующего. Это низкоуровневый инструмент, но он не мешает работе системы типов. Поэтому было бы странно писать «безопасную» операцию так же, как «опасную».

В самом деле, если вы написали их таким же образом, это начнет вызывать вопросы, почему это достаточно четко определено:

float f = 20.4f;
int i = reinterpret_cast<int>(f);

Но это как-то плохо:

float f = 20.4f;
int &i = reinterpret_cast<int &>(f);

И, конечно же, юрист по языку или кто-то, кто знаком со строгим правилом псевдонима, поймет, почему последнее плохо. Но для непрофессионала, если использование reinterpret_cast для преобразования битов нормально, неясно, почему неправильно использовать reinterpret_cast для преобразования указателей / ссылок и интерпретации существующего объекта как преобразованного типа.

Разные инструменты следует писать по-разному.

Существует фундаментальное несоответствие между современной строгой интерпретацией языковых стандартов C и C++ компиляторами в высокоуровневой языковой природе и представлением о том, что вы можете использовать reinterpret_cast для переинтерпретации группы байтов как других объектов. Обратите внимание, что так называемое правило «строгого псевдонима» в большинстве случаев не может даже использоваться для дисквалификации любой попытки переинтерпретации байтов, поскольку код изначально не определял бы поведение: reinterpret_cast<float*>(&Int) даже не является указателем на объект с плавающей запятой, это указатель на целое число неправильного типа. Вы не можете разыменовать его, поскольку в этом месте не создан объект типа float; если бы он был, его жизнь не началась бы; и если бы его время жизни началось, оно было бы неинициализированным.

Байты, которые представляют собой действительный образец битов с плавающей запятой, просто не могут быть интерпретированы как таковые, если у вас нет здесь подходящего объекта с плавающей запятой.

Допустимый ненулевой указатель - это не просто типизированное значение начального адреса области, которая оказывается правильно выровненной; ненулевой действительный указатель указывает на конкретный объект (или один за концом массива или тривиальный «массив» одного объекта).

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

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