Любой тип данных\код, который использует int, использует его интерпретацию основанную на его представлении. Представление для конкретной архитектуры фиксировано и хорошо известно, включая диапазон значений. two's-complement 32 bit signed integer это представление. Интерпретаций естественно может существовать бесконечное множество.
My point is, если хочется ограничивать диапазон допустимых значений, то нужно ограничивать диапазон интерпретаций, а не влиять на представление. Проще говоря если понимать int *меньше* numberBits *больше* как попытку сделать представление в битах определенной длинны, то это либо бред, либо misleading из-за названия типа и параметра типа. =P
В один байт компилятор/JIT может захуячить структуру вроде: { int<1..5> a; int<1..5> b; int<0..9> c; } А может и 3 DWORD'а сделать, смотря что эффективней это не сделать только задавая длину поля в битах
Примерно по этим же самым причинам битовые поля считаются плохо переносимыми, а им уже много лет. Упаковка нескольких чисел в один байт с нефиксированными границами внутри сведет с ума процессор на ALU. Ну и делать представление базового типа зависящим от чего-то кроме платформы это кошмар.
Ну так речь и идет о том, что мы декларируем платформонезависимые диапазоны, а при запуске бинарника на разных платформах получаем разный ассемблерный код и разную паковку структур в памяти.
На этапе компиляции такие ошибки можно обнаружить при присваивании значений известных опять же на этапе компиляции. Остальные ошибки такого рода все равно придется решать в рантайме, а их именно так и решают сейчас, когда *интерпретация* инта не совпадает с требуемым диапазоном\набором значений.
Другое дело что тогда выброс исключения\assert\what-you-have будут локализованы, но ни что не мешает написать приблизительно тоже самое сейчас в виде типа данных с контрактом на изменение значения представленное базовым интом.
Просто чекать range даже мне не нужно :) А выбирать storage type (сколько бит выделять) в зависимости от ranges и результатов операций над ними - было бы не плохо.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2009-10-16 09:31 am (UTC)no subject
Date: 2009-10-16 09:45 am (UTC)My point is, если хочется ограничивать диапазон допустимых значений, то нужно ограничивать диапазон интерпретаций, а не влиять на представление. Проще говоря если понимать int *меньше* numberBits *больше* как попытку сделать представление в битах определенной длинны, то это либо бред, либо misleading из-за названия типа и параметра типа. =P
no subject
Date: 2009-10-16 10:11 am (UTC){
int<1..5> a;
int<1..5> b;
int<0..9> c;
}
А может и 3 DWORD'а сделать, смотря что эффективней
это не сделать только задавая длину поля в битах
no subject
Date: 2009-10-16 10:56 am (UTC)no subject
Date: 2009-10-16 05:05 pm (UTC)Ну так речь и идет о том, что мы декларируем платформонезависимые диапазоны, а при запуске бинарника на разных платформах получаем разный ассемблерный код и разную паковку структур в памяти.
no subject
Date: 2009-10-16 10:13 am (UTC)no subject
Date: 2009-10-16 10:54 am (UTC)Другое дело что тогда выброс исключения\assert\what-you-have будут локализованы, но ни что не мешает написать приблизительно тоже самое сейчас в виде типа данных с контрактом на изменение значения представленное базовым интом.
no subject
Date: 2009-11-28 11:39 pm (UTC)range<0, 255> a;
range<-10, 10> b;
a += b; // Error: Range check failed
хотя его довольно просто написать. Быть может, это никому не нужно?
ps Какбы намекну, что множество всех предикатов значительно мощнее множества предикатов вида P = {a <= x <= b}.
no subject
Date: 2009-11-28 11:47 pm (UTC)no subject
Date: 2009-11-29 12:54 am (UTC)А выбирать storage type (сколько бит выделять) в зависимости от ranges и результатов операций над ними - было бы не плохо.