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

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

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

N>Пусть у нас 16-битная платформа (чтобы числа не были страшными) и адреса от 0 до 65535.
N>Для size_t достаточно 16 бит. Для ptrdiff_t, чтобы поддержать все значения от +65535 до -65535 — 17 бит.

N>Проблема общеизвестная, и её решают тем, что ни одному объекту не позволяют достигать в размере 1/2 адресного пространства (причём требование именно "меньше space/2", а не "не больше space/2"! потому что в дополнительном коде +32768 тоже не влезет). Но это значит, что для size_t достаточно на один бит меньше (15, а не 16). Ч.Т.Д.

Да, согласен . На один бит. Но не "гораздо меньше".

N>(Реально на современных платформах общего пользования это обеспечивается тем, что половина адресного пространства занята ядром, а в остальном есть ещё код, стек и т.п.
N>Но на embedded запросто получить и более хитрые конфигурации, в которых проблема может вылезти в полный рост.)

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

N>А с чего бы это быть той проверке? Есть масса других вариантов обойти.

Ну хз. Тут видно, один лишний test https://gcc.godbolt.org/z/HZBYFv