Обработка порядка байтов значений с плавающей запятой, когда недоступен фиксированный размер с плавающей запятой
Я пишу программу чтения / записи двоичных файлов и решил, что для решения проблемы порядка байтов я преобразую все данные в «сетевой» (большой) порядок записи и к порядковый номер хоста при чтении. Я избегаю hton* потому что я не хочу связываться с winsock только для этих функций.
Моя главная путаница заключается в том, как обрабатывать значения с плавающей запятой. Для всех интегральных значений у меня есть размерные типы в <cstdint> (uint32_tи т. д.), но из моего исследования не существует такого эквивалента для типов с плавающей запятой. Я хотел бы преобразовать все значения с плавающей запятой в 32-битное представление при записи и преобразовать обратно в ту точность, которая используется на хосте (32-битного достаточно для моего приложения). Таким образом, я буду точно знать, сколько байтов нужно записать и прочитать для значений с плавающей запятой; в отличие от того, если бы я использовал sizeof(float) а также sizeof(float) отличался на машине, загружающей файл, от машины, которая его написала.
Я только что узнал о возможности использования frexp чтобы получить мантиссу и экспоненту в целочисленных терминах, выписать эти целые числа (с некоторым фиксированным размером), затем прочитать целые числа и восстановить значение с плавающей запятой, используя ldexp. Это выглядит многообещающе, но Мне интересно, есть ли какой-либо общепринятый или рекомендуемый метод для обработки порядка байтов с плавающей запятой без htonf/ntohf.
Я почти наверняка знаю, на какую платформу я буду ориентироваться в ближайшее время. float представлены 32-битными, но я хотел бы сделать код, который я пишу сейчас, максимально совместимым для использования в будущих проектах.
Решение
Если вы хотите быть полностью кроссплатформенным и совместимым со стандартами, то frexp/ldexp Решение — лучший путь. (Хотя вам, возможно, придется рассмотреть весьма теоретический случай, когда исходное или целевое оборудование использует десятичную с плавающей запятой.)
Предположим, что на одной или другой машине не было 32-битного представления с плавающей запятой. Кроме того, на этой машине отсутствует тип данных, совместимый с 32-разрядным плавающим номером указателя, независимо от порядкового номера. Таким образом, тогда не существует стандартного способа преобразования не 32-разрядного числа с плавающей запятой в передаваемое 32-разрядное представление или преобразования переданного 32-разрядного представления в собственное не 32-разрядное число с плавающей запятой.
Вы можете ограничить область действия машинами, которые имеют 32-битное представление с плавающей запятой, но тогда вам нужно будет предположить, что обе машины имеют одинаковое количество и порядок битов, предназначенных для знака, экспоненты и мантиссы. Вероятно, так оно и есть, поскольку формат IEEE-754 в наши дни практически универсален, но C ++ на этом не настаивает, и, по крайней мере, возможно, что есть машина, которая реализует 1/8/23-битные числа с плавающей запятой с знаковый бит на младшем конце вместо старшего конца.
Короче говоря, порядковый номер — это только одна из возможных несовместимостей между двоичными форматами с плавающей запятой. Сокращение каждого числа с плавающей запятой до двух целых, однако, позволяет избежать необходимости иметь дело с другими несовместимостями (кроме оснований).
Другие решения
Других решений пока нет …