На практике или в теории. Что касается стандарта, я не
думаю, что есть гарантия, что pos_type
даже конвертируется в
интегральный тип; по логике, это не должно быть, так как он содержит несколько
независимые данные: смещение от начала файла и
информация о состоянии для многобайтового декодирования.
На практике, с другой стороны, у вас не должно быть проблем с
Машины на базе Unix; в Windows числовое значение не обязательно
много значат, если файл открывается в текстовом режиме, но вы можете преобразовать
pos_type
до uint64_t
и обратно без потери стоимости (если нет
действительно значимое многобайтовое состояние в оригинале pos_type
, но я
не знаю ни одной кодировки под Windows, где это было бы так).
Должно быть возможно определить во время компиляции, pos_type
будет неявно преобразовывать в целочисленный тип или нет, и использовать это в некоторых
вроде static_assert
. Я не думаю, что это много покупает, однако; Это
не будет определять, можно ли использовать интегральное значение, кроме
чтобы вернуться обратно к pos_type
. (Это может быть какая-то магия
печенье, например. Но я бы не стал сильно беспокоиться об этом.
Стандарт допускает много вещей, которые ни одна разумная реализация не будет
делать. Просто имейте в виду, что даже под Windows значение не всегда
представляет точное количество байтов, которые могут быть прочитаны.