Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Ну да, естественно. Но r-то от этого не перестает быть натуральным.

Разумеется, это не натуральное, а целое положительное! Потому что запись -r не существует в моноиде натуральных чисел. Как раз в этом надуманном, но правомерном примере видно, что лучше проверить значение r при вводе один раз, а потом использовать свободно, чем каждый раз кастовать его к правильному типу. Притом, что проверять всё равно придётся, ведь r должен быть небольшим по факту, а ещё и меньше, чем размер сигнала.

Здравствуйте, netch80, Вы писали:

H>>>Во-вторых, иногда нужно не-валидное значение чего-то, что по смыслу неотрицательно. И для этого я лично использую «-1». И если переменная равна ему, то значит значение невалидное. Такая штука с unsigned не проканает, если не вводить всякие magic digits конечно.
PJ>>std::optional<uint>
N>И терять 4-8 байт вместо одного бита ;[
корретное поведение вместо креша того стоит.

Здравствуйте, Marty, Вы писали:


M>2 миллиарда байт в векторе — вполне себе норм, и ровно 2 гига + 15 байт на гранулярность

Вот только 2 миллиарда байтов мало кому нужно, чаще там более сложные структуры, поэтому размер увеличится в несколько раз.


>>>размера и позиции в файловых потоках.

PD>>А вот это да. Это непростительно.

M>Нормально. Знак может показывать, откуда отсчитываем — от начала или конца. Какая разница, знаковый или беззнаковый?

Речь шла о int как позиции в файлах. +-2Гб для фалов действительно мало.

Здравствуйте, Pavel Dvorkin, Вы писали:

M>>2 миллиарда байт в векторе — вполне себе норм, и ровно 2 гига + 15 байт на гранулярность

PD>Вот только 2 миллиарда байтов мало кому нужно, чаще там более сложные структуры, поэтому размер увеличится в несколько раз.

А если не байты, а структуры, то там наверно не два байта, а несколько целых. И тут гранулярность съедает гораздо меньше. Ты-то гранулярность посчитал для байтов.


>>>>размера и позиции в файловых потоках.

PD>>>А вот это да. Это непростительно.

M>>Нормально. Знак может показывать, откуда отсчитываем — от начала или конца. Какая разница, знаковый или беззнаковый?

PD>Речь шла о int как позиции в файлах. +-2Гб для фалов действительно мало.

Я понял. И +4Гб для файлов это тоже ни о чём

Здравствуйте, Marty, Вы писали:

M>А если не байты, а структуры, то там наверно не два байта, а несколько целых. И тут гранулярность съедает гораздо меньше. Ты-то гранулярность посчитал для байтов.

Если несколько целых (не больше 4), то 16 и получится. и при 2 миллиардах элементов в массиве и будет 32 Гб.

PD>>Речь шла о int как позиции в файлах. +-2Гб для фалов действительно мало.

M>Я понял. И +4Гб для файлов это тоже ни о чём

Теперь я уже не понял, о чем ты. Я лишь согласился с мнением PM, что 32 бита в файловом смещении никуда не годится.

Здравствуйте, Pavel Dvorkin, Вы писали:

M>>А если не байты, а структуры, то там наверно не два байта, а несколько целых. И тут гранулярность съедает гораздо меньше. Ты-то гранулярность посчитал для байтов.

PD>Если несколько целых (не больше 4), то 16 и получится. и при 2 миллиардах элементов в массиве и будет 32 Гб.

А если байты — то 2Гб, если 32х-битные значения — то 8Гб, а если структуры размером 12 байт — то 24 Гб. Если говорить о векторе. Если списки/деревья и тп — то там о размере реально занимаемой памяти вообще сложно говорить, и гранулярность маллока уже рояли особой не играет


PD>>>Речь шла о int как позиции в файлах. +-2Гб для фалов действительно мало.

M>>Я понял. И +4Гб для файлов это тоже ни о чём

PD>Теперь я уже не понял, о чем ты. Я лишь согласился с мнением PM, что 32 бита в файловом смещении никуда не годится.

А, я так понял, что проблема в том, что позиция — знаковая, а не в её 32х-битности. И так-то int не обязан быть 32х-битным. Хотя, вроде на x64 вроде оставили его 32х битным, а вот вроде long уже зависит от компилятора/системы

V> Если этот код загнать на платформу, в которой размер int равен размеру указателя — беззнаковый вариант будет, как минимум, не хуже. А обычно он чуть-чуть лучше.

Размер указателя и результата их вычитания не обязаны совпадать.

V>Очевидно, что проблему можно решить и более правильно — путем использования уместного типа, std::size_t. Ирония заключается в том, что size_t — без-знаковый тип.

Причем тут size_t и почему ты считаешь, что он "более уместен"? Результат вычитания двух указателей имеет тип ptrdiff_t. Можно легко представить платформу, где первый гораздо меньше второго.

Я могу понять, почему используют int, но уж если использовать специальный тип, то следует использовать правильный.

Здравствуйте, T4r4sB, Вы писали:

ЕМ>>Лично у меня статистика весьма показательная — касты используются исключительно там, где передавать натуральные числа под видом целых вынуждают сторонние API.

TB>А также при записи выражений типа
TB>

TB>for (... i < static_cast<size_t>(some_expression(static_cast<int>(i)))
TB>

Возможно, Вы удивитесь, но подобное встречается у меня в единичных случаях на десятки тысяч строк кода. Как раз там, где я получаю от API фактически натуральное значение в знаковом типе, и оно используется только однажды, поэтому нет смысла перекладывать его в беззнаковую переменную.

TB>Поэтому как раз надо просто везде использовать знаковые.

Если их использовать везде, то таким же образом придется приводить значения в API, где используются беззнаковые типы. Но это уже будет не просто мелкое неудобство, а откровенная кривизна.

Здравствуйте, Nuzhny, Вы писали:

ЕМ>>Вы где-нибудь видели математическую запись суммы или произведения по i/k, где было бы оговорено, что i/k принадлежат кольцу целых чисел?

N>Слово "кольцо" обычно опускают.

Точнее — подразумевают или оговаривают, что i/k являются натуральными числами.

N>Но суммы, где индекс отрицательный встречаются очень часто: пределы интегрирования, например.

Интегрирование по целой переменной? Хотя мне с трудом и удалось найти обычное суммирование с отрицательным индексом. Какую долю такие случаи составляют в общей массе?

Здравствуйте, Nuzhny, Вы писали:

N>Разумеется, это не натуральное, а целое положительное!

Любое целое положительное число является натуральным.

N>Потому что запись -r не существует в моноиде натуральных чисел.

А ей нужно в нем существовать? Зачем?

N>Как раз в этом надуманном, но правомерном примере видно, что лучше проверить значение r при вводе один раз, а потом использовать свободно, чем каждый раз кастовать его к правильному типу. Притом, что проверять всё равно придётся, ведь r должен быть небольшим по факту, а ещё и меньше, чем размер сигнала.

Не понял тонкости. Проверять нужно и так и так. А насколько часто Вам требуется, имея r, получить -r, что держать r в беззнаковом типе однозначно выгоднее?

Здравствуйте, Евгений Музыченко, Вы писали:

N>>Разумеется, это не натуральное, а целое положительное!
ЕМ>Любое целое положительное число является натуральным.

Да, но не в этом случае: тут натуральность — это частный случай. А ожидается именно целое оложительное.

N>>Потому что запись -r не существует в моноиде натуральных чисел.
ЕМ>А ей нужно в нем существовать? Зачем?

Потому что код не будет работать без явного каста к целому. Множество натуральных чисел не замкнуто относительно операции вычитания, в нём нет противоположного элемента, поэтому выбирают более подходящее множество. В моём коде беззнаковые только индексы при итерации по контейнерам (из-за STL) и всякие флаги. Ну и внешнее API, если надо. И то не все индексы из-за обратного прохода по циклам и openmp.

ЕМ>Не понял тонкости. Проверять нужно и так и так. А насколько часто Вам требуется, имея r, получить -r, что держать r в беззнаковом типе однозначно выгоднее?

Проверять для знакового надо 1 раз при вводе, а дальше просто пользоваться. Если же будет беззнаковое, то его ещё и кастовать остоянно придётся. По факту ВСЕ оконные координаты в пикслях знаковые, потому что они могут быть отрицательными. Все размеры изображений знаковые, потому что они тоже могут стать отрицательными в результате преобразований — корректных преобразований. И намного проще потом диагностировать почему значение ширины стало -5, а не, скажем, 4294967291. Потому что при -5 оно просто исчезнет или окажется с противоположной стороны. Далее скорости, которые тоже могут измеряться в икселях тоже знаковые. Сдвинули объект, у него окзались отрицательные координаты — обработали. Были бы они беззнаковыми, получилась бы либо лапша проверок в коде, либо завёрнутая внутри методов. И так повсюду.
Оказалось, что беззнаковые нужны за редким исключением, чаще всего для редкого внешнего API, где просто нет вычитания.

Здравствуйте, Vamp, Вы писали:


V>> Если этот код загнать на платформу, в которой размер int равен размеру указателя — беззнаковый вариант будет, как минимум, не хуже. А обычно он чуть-чуть лучше.

V>Размер указателя и результата их вычитания не обязаны совпадать.

Ага. Этим я хотел показать что приведенный тобою проблематичный пример — он платформ-специфик. Не носит универсального характера. Частный случай.

V>>Очевидно, что проблему можно решить и более правильно — путем использования уместного типа, std::size_t. Ирония заключается в том, что size_t — без-знаковый тип.

V>Причем тут size_t и почему ты считаешь, что он "более уместен"? Результат вычитания двух указателей имеет тип ptrdiff_t. Можно легко представить платформу, где первый гораздо меньше второго.

size_t меньше ptrdiff_t? Вряд ли. Стандарт требует чтобы этот тип вмещал размер любого объекта, включая тот самый массив, разницу индексов которого вмещает ptrdiff_t. Таким образом, он гарантированно не меньше ptrdiff_t.

Он "более уместен" потому что не имеет знака, который на самом деле не нужен. Из за этого, например, мой компилятор не генерирует дополнительную проверку на отрицательность в том цикле. То есть, получается код на одну инструкцию короче. Да, она не в теле цикла, а в шапке, но все же.

V>Я могу понять, почему используют int, но уж если использовать специальный тип, то следует использовать правильный.

Вообще, правда у каждого своя.

Здравствуйте, Pavel Dvorkin, Вы писали:

[]

PD>… если в результате арифметики с положительными числами результат оказался отрицательным там, где такого не должно быть,то ошибку надо искать в алгоритме …

ЕМНИП, это UB, нет? Как можно тут рассуждать должно/не должно?

Здравствуйте, Alexander G, Вы писали:


AG>- fused операция при сравнении и переходе: while (i > 0) или for ( i ; i < 10 ; i++ ) CMP и JCC выполняются как одна операция только для беззнаковых.

Это не так и при чем уже довольно давно.

Здравствуйте, Философ, Вы писали:

Ф>Особенно, когда отрицательным значением задаются размеры в структурах: мы ведь не можем быть уверены, что переданный буфер не имеет отрицательного размера.

Можно написать assert...
Для знакового размера, кстати, его писать проще и понятнее, чем для беззнакового.

Здравствуйте, T4r4sB, Вы писали:

TB>Ты на беззнаках даже тупо от ЭН до нуля проитерироваться не можешь без дополнительного бубна.

А как же "оператор стремления к нулю"?

size_t i = n;
while(i-->0) {
    // Тут что-то делаем с n-1, n-2, ..., 1, 0
}

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Индекс в массиве это полноценная сущность БД. Используется вместо указателей.
SVZ>В этом случае отрицательные значения используются для обозначения невалидных объектов (у нас это -1) и для каких-нибудь специальных констант.

Ну тут UINT_MAX ничем не хуже. Даже битики теже самые

Здравствуйте, T4r4sB, Вы писали:

TB>В какой нормальной команде допустимы такие заголовки for?

А while у вас тоже запрещены?

Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, Евгений Музыченко, Вы писали:

TB>Знаковые целые тупо безопаснее. Беззнаковость в STL — это огромная историческая ошибка, даже Степанов это признал.
TB>Ты на беззнаках даже тупо от ЭН до нуля проитерироваться не можешь без дополнительного бубна.

Как правило, люди, которые приводят такой аргумент слабо умеют работать с итераторами. То есть они как бы в теории знают про итераторы, но им лень. Могут быть крутыми алгоритмистами, но даже банальный бинарный поиск не могут нормально написать. Будут сплошные int под 64 битную платформу и (a + b) / 2.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Даже во многих современных программах на C++ часто вижу int/short/long там, где по смыслу должно быть беззнаковое целое. А в ранних программах знаковые целые вообще использовались везде, где было технически возможно. Даже в классической книге Кернигана/Ритчи множество примеров, где счетчики, индексы и прочие имеют знаковый тип. В виндовых SDK, где знаковость в основном используется адекватно, все равно регулярно встречаются знаковые параметры размеров, количеств и прочего, где не используются отрицательные значения для особых случаев.

ЕМ>Откуда такое пристрастие, кроме как от лени? Вроде как сколько-нибудь массовых процессоров, где беззнаковые целые поддерживались бы ограниченно, не существует. Есть в этом хоть какое-то рациональное зерно?

Я против использования знаковых там, где значение беззнаковое. Отчего любовь у людей? От недостатков мышления.

Для того, чтобы доказать, что это именно недостатки мышления, рассмотрим критерии.
1. Любители знаковых индексов обычно используют int там, где диапазона значений int недостаточно (64битная платформа).
2. Пользоваться итераторами не умеют. Попробуйте попросить такого человека написать бинарный поиск. Он его напишет с помощью int, а средний элемент будет вычислять с как (a + b) / 2.
3. В связи с тем, что используются знаковые числа, код кишит мусорными проверками (как условия, так и assert) на неотрицательность числа. Из-за этого код становится запутанным и легко содержит ошибки.
Из-за того, что некоторая функция становится толерантной к тому, что туда передают отрицательный индекс, нарастает куча извращенной логики в других местах.
В случае с беззнаковыми сразу понятно, что значение от 0 до max. Не нужно делать лишних runtime проверок типа assert(index >= 0) или, что ещё хуже if (index < 0) return; Это всё признаки грязного кода.

Я ещё не видел человека, который бы писал ЧИСТЫЙ код и любил бы int.