Сообщение Re: Откуда эта лютая любовь к знаковым целым? от 05.05.2020 4:38
Изменено 05.05.2020 4:39 Nuzhny
Re: Откуда эта лютая любовь к знаковым целым?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Откуда такое пристрастие, кроме как от лени? Вроде как сколько-нибудь массовых процессоров, где беззнаковые целые поддерживались бы ограниченно, не существует. Есть в этом хоть какое-то рациональное зерно?
Что сразу вспомнилось:
1. Про итерирование от N до 0 уже написали, но повторюсь.
2. OpenMP. Неожиданно, но Майкрософт в своём компиляторе поддерживает только очень старую версию 2.0, в ней индексы для for могут быть только знаковыми.
3. Адресная арифметика вся знаковая, родной тип ptrdiff_t. То есть если я захочу сделать размеры картинки (ширину и высоту) сделать, например, size_t и ходить по изображению по байтам, то мне всё равно надо переходить к ptrdiff_t, чтобы компилятор не ругался.
4. Внезапно оказывается, что многие типы становятся знаковыми, хотя по логике они такими быть, на первый взгляд, не могут. Например, детектирую я пешеходов и авто на кадре. И их левая координата уходит в минус, если в кадре видна только часть автомобиля.
5. Далее знаковые становятся удобнее, когда происходит преобразование в другие системы координат. В твоей экранной системе координаты только положительные, ты рисуешь график в декартовой и числа внезапно становятся отрицательными.
6. Даже яркость пикселя, которая чаще всего от 0 до 255 и представлена в uchar при манипуляциях с яркостью легко вылезает за пределы типа вверх и вниз, поэтому тут либо ставить кучу проверок, либо при манипуляциях кастовать в int, а потом обратно. Хотя тут больше есть ограничение на тип, но если сделать его и uint64, легче не станет.
Получается, что большая часть моих кейсов сводится к тому, что естественные ограничения на беззнаковость идут к херам при вычислениях с этими типами. Насколько размер одного контейнера больше второго? Нельзя просто так взять и вычесть! Надо написать if (v1.size() > v2.size())...
Ye relf nfrjt ujlbncz&
ЕМ>Откуда такое пристрастие, кроме как от лени? Вроде как сколько-нибудь массовых процессоров, где беззнаковые целые поддерживались бы ограниченно, не существует. Есть в этом хоть какое-то рациональное зерно?
Что сразу вспомнилось:
1. Про итерирование от N до 0 уже написали, но повторюсь.
2. OpenMP. Неожиданно, но Майкрософт в своём компиляторе поддерживает только очень старую версию 2.0, в ней индексы для for могут быть только знаковыми.
3. Адресная арифметика вся знаковая, родной тип ptrdiff_t. То есть если я захочу сделать размеры картинки (ширину и высоту) сделать, например, size_t и ходить по изображению по байтам, то мне всё равно надо переходить к ptrdiff_t, чтобы компилятор не ругался.
4. Внезапно оказывается, что многие типы становятся знаковыми, хотя по логике они такими быть, на первый взгляд, не могут. Например, детектирую я пешеходов и авто на кадре. И их левая координата уходит в минус, если в кадре видна только часть автомобиля.
5. Далее знаковые становятся удобнее, когда происходит преобразование в другие системы координат. В твоей экранной системе координаты только положительные, ты рисуешь график в декартовой и числа внезапно становятся отрицательными.
6. Даже яркость пикселя, которая чаще всего от 0 до 255 и представлена в uchar при манипуляциях с яркостью легко вылезает за пределы типа вверх и вниз, поэтому тут либо ставить кучу проверок, либо при манипуляциях кастовать в int, а потом обратно. Хотя тут больше есть ограничение на тип, но если сделать его и uint64, легче не станет.
Получается, что большая часть моих кейсов сводится к тому, что естественные ограничения на беззнаковость идут к херам при вычислениях с этими типами. Насколько размер одного контейнера больше второго? Нельзя просто так взять и вычесть! Надо написать if (v1.size() > v2.size())...
Ye relf nfrjt ujlbncz&
Re: Откуда эта лютая любовь к знаковым целым?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Откуда такое пристрастие, кроме как от лени? Вроде как сколько-нибудь массовых процессоров, где беззнаковые целые поддерживались бы ограниченно, не существует. Есть в этом хоть какое-то рациональное зерно?
Что сразу вспомнилось:
1. Про итерирование от N до 0 уже написали, но повторюсь.
2. OpenMP. Неожиданно, но Майкрософт в своём компиляторе поддерживает только очень старую версию 2.0, в ней индексы для for могут быть только знаковыми.
3. Адресная арифметика вся знаковая, родной тип ptrdiff_t. То есть если я захочу сделать размеры картинки (ширину и высоту) сделать, например, size_t и ходить по изображению по байтам, то мне всё равно надо переходить к ptrdiff_t, чтобы компилятор не ругался.
4. Внезапно оказывается, что многие типы становятся знаковыми, хотя по логике они такими быть, на первый взгляд, не могут. Например, детектирую я пешеходов и авто на кадре. И их левая координата уходит в минус, если в кадре видна только часть автомобиля.
5. Далее знаковые становятся удобнее, когда происходит преобразование в другие системы координат. В твоей экранной системе координаты только положительные, ты рисуешь график в декартовой и числа внезапно становятся отрицательными.
6. Даже яркость пикселя, которая чаще всего от 0 до 255 и представлена в uchar при манипуляциях с яркостью легко вылезает за пределы типа вверх и вниз, поэтому тут либо ставить кучу проверок, либо при манипуляциях кастовать в int, а потом обратно. Хотя тут больше есть ограничение на тип, но если сделать его и uint64, легче не станет.
Получается, что большая часть моих кейсов сводится к тому, что естественные ограничения на беззнаковость идут к херам при вычислениях с этими типами. Насколько размер одного контейнера больше второго? Нельзя просто так взять и вычесть! Надо написать if (v1.size() > v2.size())...
Ну куда такое годится?
ЕМ>Откуда такое пристрастие, кроме как от лени? Вроде как сколько-нибудь массовых процессоров, где беззнаковые целые поддерживались бы ограниченно, не существует. Есть в этом хоть какое-то рациональное зерно?
Что сразу вспомнилось:
1. Про итерирование от N до 0 уже написали, но повторюсь.
2. OpenMP. Неожиданно, но Майкрософт в своём компиляторе поддерживает только очень старую версию 2.0, в ней индексы для for могут быть только знаковыми.
3. Адресная арифметика вся знаковая, родной тип ptrdiff_t. То есть если я захочу сделать размеры картинки (ширину и высоту) сделать, например, size_t и ходить по изображению по байтам, то мне всё равно надо переходить к ptrdiff_t, чтобы компилятор не ругался.
4. Внезапно оказывается, что многие типы становятся знаковыми, хотя по логике они такими быть, на первый взгляд, не могут. Например, детектирую я пешеходов и авто на кадре. И их левая координата уходит в минус, если в кадре видна только часть автомобиля.
5. Далее знаковые становятся удобнее, когда происходит преобразование в другие системы координат. В твоей экранной системе координаты только положительные, ты рисуешь график в декартовой и числа внезапно становятся отрицательными.
6. Даже яркость пикселя, которая чаще всего от 0 до 255 и представлена в uchar при манипуляциях с яркостью легко вылезает за пределы типа вверх и вниз, поэтому тут либо ставить кучу проверок, либо при манипуляциях кастовать в int, а потом обратно. Хотя тут больше есть ограничение на тип, но если сделать его и uint64, легче не станет.
Получается, что большая часть моих кейсов сводится к тому, что естественные ограничения на беззнаковость идут к херам при вычислениях с этими типами. Насколько размер одного контейнера больше второго? Нельзя просто так взять и вычесть! Надо написать if (v1.size() > v2.size())...
Ну куда такое годится?