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

EP>Не не не, Дэвид Блэйн, меня ты не проведёшь.
EP>Там где проявляется закольцованность у безнаковых, у знаковых вообще случается undefined behaviour (речь же о C++?). Причём для индексов случается чаще, в силу меньшего положительного диапазона.
EP>В одном случае имеем чёткую модель кольца, а в другом даже магмы нет, ибо операции не замкнуты

Я бы понял, если бы ты топил за long long вместо int, но при чём тут unsigned?
Идея-то в том, что иы НЕ ХОТИМ попадать в область "закольцованности" операций, а не в том, что в одном типе поведение в этой области нам нравится больше, чем в другом...

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

E>>>И в этом смысле семантика индексов -- это тоже отрезок целого ряда, просто другой. И создавать его поверх отрезка целых [INT_MIN, INT_MAX] намного естественнее, чем над кольцом по модулей вычетов.
EP>>Не не не, Дэвид Блэйн, меня ты не проведёшь.
EP>>Там где проявляется закольцованность у безнаковых, у знаковых вообще случается undefined behaviour (речь же о C++?). Причём для индексов случается чаще, в силу меньшего положительного диапазона.
EP>>В одном случае имеем чёткую модель кольца, а в другом даже магмы нет, ибо операции не замкнуты
E>Я бы понял, если бы ты топил за long long вместо int, но при чём тут unsigned?
E>Идея-то в том, что иы НЕ ХОТИМ попадать в область "закольцованности" операций, а не в том, что в одном типе поведение в этой области нам нравится больше, чем в другом...

Ещё раз, ты выше (выделено) говорил про какую-то неподходящую семантику кольца вычетов по модулю.
Я не говорю что зацикленность по модулю нужна/полезна для индексов, я говорю что некорректно на эту зацикленность вообще указывать при сравнении со знаковыми, ибо там где у беззнаковых зацикленность — у знаковых UB, причём наступает раньше за счёт вдвое меньшего положительного диапазона.

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

EP>Ещё раз, ты выше (выделено) говорил про какую-то неподходящую семантику кольца вычетов по модулю.
EP>Я не говорю что зацикленность по модулю нужна/полезна для индексов, я говорю что некорректно на эту зацикленность вообще указывать при сравнении со знаковыми, ибо там где у беззнаковых зацикленность — у знаковых UB, причём наступает раньше за счёт вдвое меньшего положительного диапазона.

То, что неожиданный результат у беззнаковых наступает на 0-1, в >99% случаях важнее потенциального переполнения где-то за границей 2 миллиарда или 9 длинных триллионов: до второго надо ещё суметь достучаться на особых числах, а уйти вместо -1 в UINT_MAX банально неаккуратным действием возле нуля.

А если рассматривать не только C, а и прочие места с беззнаковыми — то там и UdB заменено обычно на что-то другое.

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

N>То, что неожиданный результат у беззнаковых наступает на 0-1
С чего это он неожиданный?

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

EP>Ещё раз, ты выше (выделено) говорил про какую-то неподходящую семантику кольца вычетов по модулю.
EP>Я не говорю что зацикленность по модулю нужна/полезна для индексов, я говорю что некорректно на эту зацикленность вообще указывать при сравнении со знаковыми,
Ну мы же про читабельность? Читабельность -- это про то, как люди понимают твой код...

EP>ибо там где у беззнаковых зацикленность — у знаковых UB, причём наступает раньше за счёт вдвое меньшего положительного диапазона.
Со словом "раньше" тут я не согласен. Зацикленность в районе 1 << 31 или 1 << 63 намного дальше, чем зацикленность в районе 0...

Ну и если уж мы боимся переполнения int32, то и uint32 не должен вызывать доверия? Тогда логичнее взять int64 (или uint64, если уж он нам так нравится)
Конечно бывают какие-то хитрые особые случаи, когда надо использовать вот прямо весь диапазон типа. Но они правда очень редкие, специальные и всё равно пишутся отдельно.
Исключение пока что ты привёл одно -- это char/byte. Но тут тоже ситуация особая. Обычно же char как индекс не выступает. Максимум, как вход в какую-то таблицу. И там уже надо смотреть, что удобнее.
Но это тоже какой-то отдельный, специальный случай. В целом не понятно зачем ради него выбирать тип индекса во всех последовательностях и итерациях...

В любом случае, мне так кажется, что я уже довольно много посвятил объяснению ответа на сабжевый вопрос. IMHO, если ты до сих пор не понял его, то не судьба видимо. Ты остальных программистов так и не поймёшь.

Чем пытаться понять нас, лучше объясни, почему ты не используешь конструкции вроде IntRange? Это же намного прямее выражает то, что ты хочешь, чем insigned?

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

ЕМ>Вас это смущает? Меня — ничуть, коли уж человек от рождения оперирует понятиями "до/после", "выше/ниже" и подобными.

Не знаю, как где, а у нас, в Сибири, человек с рождения оперирует понятием "минус 40 -- это холоднее, чем минус 20!"...

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

ЕМ>А еще в Фортране можно изменить константу, переданную параметром функции. Как будем выбирать, с чего достойно брать пример, а с чего — нет?

Это можно было только в очень древних реализациях, всё-таки... Ещё там рекурсия не работала, если что

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

ЕМ>С Ada я никогда не имел дела, а когда в детстве впервые познакомился с Pascal, идея отрезков типов меня очень впечатлила. И в C++ она пришлась бы очень кстати.

В С++ такой отрезок можно просто написать на самом С++: IntRange...
Я несколько раз просил тебя ответить, почему ты такие конструкции не используешь, вместо unsigned? Это же намного прямее выражает твои желания?

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

TB>Вот код, который честно использует возможности языка, нравится такое читать?
TB>

TB>switch (count % 8) {
TB>    case 0: do { *to = *from++;
TB>    case 7:      *to = *from++;
TB>    case 6:      *to = *from++;
TB>    case 5:      *to = *from++;
TB>    case 4:      *to = *from++;
TB>    case 3:      *to = *from++;
TB>    case 2:      *to = *from++;
TB>    case 1:      *to = *from++;
TB>               } while (--n > 0);
TB>    }
TB>

Не нравится, потому, что не понятно, как связаны переменные count и n...

А вообще-то, это история про неоптимизирующий компилятор.
Запиши ТОТ ЖЕ алгоритм лучше -- почитаем вместе...

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

TB>Ну правильно, пока паскалисты писали простенькие, но рабочие лабы, сишники понтовались очередным бессмысленным способом написать алгоритм через задницу.
Сишники весь мир юникса накропали...

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

TB>Лаконичность по числу букв сравниваешь что ли?
Видимо и правда по разному понимаете
А ты как лаконичность считаешь?

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

N>Эти "субъективные предрассудки" превращаются в объективные, когда начинаешь смотреть, как воспринимает такой код не только тот, кто всю жизнь "в системе", как я, а и, например, типовой юниор, часто к тому же перешедший с какого-то соседнего языка.

Языки С/С++ не шибко похожи на остальные C-like
Ну так это более универсальная проблема, чем странный синтаксис. Оба эти языки очень близки к аппаратуре, все их абстракции очень дырявые, и легко рвутся вниз до самого низкого железного уровня.
Так что на С/С++ вообще лучше не программировать, если хочешь, что бы всё было как на java, например...

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

E>Ну и если уж мы боимся переполнения int32, то и uint32 не должен вызывать доверия?

Ну я тебе примерно тоже самое и говорю — если смущает зациклинность беззнаковых, то и UB знаковых не должно вызывать доверия. С чем ты не согласен

E>Исключение пока что ты привёл одно -- это char/byte

E>В любом случае, мне так кажется, что я уже довольно много посвятил объяснению ответа на сабжевый вопрос. IMHO, если ты до сих пор не понял его, то не судьба видимо. Ты остальных программистов так и не поймёшь.

Ты меня видимо с кем-то перепутал.

E>Чем пытаться понять нас, лучше объясни, почему ты не используешь конструкции вроде IntRange? Это же намного прямее выражает то, что ты хочешь, чем insigned?

Не прям такое, но в целом подобный подход, в самых разных проявлениях, в том числе и для типобезопасной индексации — использую вовсю

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


EP>Ну я тебе примерно тоже самое и говорю — если смущает зациклинность беззнаковых, то и UB знаковых не должно вызывать доверия. С чем ты не согласен
Тут я ни с чем не спорю.
Есть, правда, одно замечание. Суть замечания такая, что использование unsigned констант, вроде 0xFFFFFFFF "приколачивает гвоздями" разрядность используемых unsigned целых.
Вот прикинь, есть у тебя какая-то сериализованная в файл, ещё хуже, если мапируемая на память, структура на индексах. И тебе понадобилось иметь её версию с индексами другой размерности. Что со спец. значениями делать?
А -1 от разрядности числа не зависит...

E>>Исключение пока что ты привёл одно -- это char/byte
EP>Ты меня видимо с кем-то перепутал.
Возможно перепутал с другим Евгением. Прошу прощения, если так.

EP>Не прям такое, но в целом подобный подход, в самых разных проявлениях, в том числе и для типобезопасной индексации — использую вовсю
Так а на фига тогда козе боян unsigned?

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

E>Есть, правда, одно замечание. Суть замечания такая, что использование unsigned констант, вроде 0xFFFFFFFF "приколачивает гвоздями" разрядность используемых unsigned целых.
E>Вот прикинь, есть у тебя какая-то сериализованная в файл, ещё хуже, если мапируемая на память, структура на индексах. И тебе понадобилось иметь её версию с индексами другой размерности. Что со спец. значениями делать?

А спец значения подобного рода выражаются не литералами, а через numeric_limits<T>::max/lowest()

E>А -1 от разрядности числа не зависит...

Для знаковых частенько использую ::lowest(), а не -1. И кстати, в контексте сериализации, битовое представление -1 оно разное может быть, то бишь implementation-defined

Здравствуйте, Evgeny.Panasyuk, Вы писали:
E>>Есть, правда, одно замечание. Суть замечания такая, что использование unsigned констант, вроде 0xFFFFFFFF "приколачивает гвоздями" разрядность используемых unsigned целых.
E>>Вот прикинь, есть у тебя какая-то сериализованная в файл, ещё хуже, если мапируемая на память, структура на индексах. И тебе понадобилось иметь её версию с индексами другой размерности. Что со спец. значениями делать?

EP>А спец значения подобного рода выражаются не литералами, а через numeric_limits<T>::max/lowest()
Да какая разница, литерал, константа, или какое-то ct-константное выражение? Суть в том, что магические константы разных размерностей могут лежать в данных. И то, что магическая константа будет зависеть от разрядности её хранилища -- это конкретная кривизна варианта с беззнаковыми целыми...

E>>А -1 от разрядности числа не зависит...

EP>Для знаковых частенько использую ::lowest(), а не -1. И кстати, в контексте сериализации, битовое представление -1 оно разное может быть, то бишь implementation-defined
Может, и что? Мало того, у целых разных разрядностей битовое представление разное. Даже не только у -1, а у любых. Например, у них (представлений) разный размер...
Тем не менее, ЗНАЧЕНИЯ констант вроде -1, у целых разных размерностей будут совпадать, хотя битовые представления и не будут.
Логический уровень не будет зависеть от разрядности типа, используемого как хранилище индекса, например...

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

ЕМ>Спросите математиков, зачем они делят числа на целые и натуральные, а не обходятся только целыми. Универсальнее же.

А ты видел код, который обычно пишут математики (да и в принципе большинство товарищей в академии)? Ты точно хочешь равняться на их стиль? Лично я считаю, что чтение такого кода нарушает конвенцию ООН по недопустимым методам пыток.

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

ЕМ>... где счетчики, индексы и прочие...

Евгений, с Вашей педантичностью и Вашим стремлением к перфекциони́зму , я ожидал увидеть букву ё в слове счётчики

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

EP>Ну я тебе примерно тоже самое и говорю — если смущает зациклинность беззнаковых, то и UB знаковых не должно вызывать доверия. С чем ты не согласен

UB знаковых возникает примерно никогда, потому что числа вида +- 2 лярда очень нетипичные
Зацикленность знаковых возникает чисто случайно, потому что случайно вычесть из меньшего большее и сравнить с i — это очень растая операция, потому что область вокруг нуля вся используется в расчётах постоянно.

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

AG>>>Обычное деление достаточно больших чисел int64_t / uint64_t, компиляция MSVC x64, беззнаковые ощутимо быстрее. Нужно воспроизвести?
N>>Это уже речь про деление, а перед этим было про умножение
N>>Вообще, если настроение, киньте код, я сверю в своих условиях.

AG> // чтобы не выоптимизировались; компиляторы пока ещё не научились оптимизировать атомики

Ошибаетесь: clang (>=6) научился
пришлось заменить везде тут на `volatile int`.

AG> std::cout << Benchmark<std::uint64_t>{}.Run().count() << "ms unsinged\n";
AG> std::cout << Benchmark<std::int64_t>{}.Run().count() << "ms singed\n";

Проверил. Я дополнительно подновил на возможность замены делителя, сравнил без умножения и менял делимое, везде одинаково:

Intel i3-4170 — ~12% добавки (тут и дальше — на знаковых).
Intel i3-8145U — ~12% добавки.
Intel Xeon E5345: ~25% добавки.
Intel i5-1035G1: разницы нет.
AMD Athlon(tm) 64 Processor 3500+: ~8% добавки.
AMD Ryzen 5 2400G: разницы нет.
Подходящего ARM под рукой нет. Если есть — проверьте там

Ну что тут сказать... почему-то у Intel очень долго была такая специфика: они всегда хуже делали арифметику, а деление у них вообще в загоне. Правильные методы работы с денормализованными (которые не тратят до 200 тактов на операцию) AMD начал внедрять на несколько лет раньше — пока Intel отделывался флажками типа "плевать на них, все меняем на ноль". Деление плавучих по Голдсмиту — тоже раньше (пока Intel сохранял SRT, знаменитый по FDIV bug). Может, для своих целей оно им и правильно... Но то, что на 10-м поколении Core разница ушла — показывает, что и они умеют учиться.