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


R>>А вариант for (size_t n = size(v); n--; ) отличается только тем, что сужает область видимости переменой цикла, вот и все.
CC>Для компилятора нет никакой разницы. Для человека — есть.

Конечно есть — сужение области видимости переменной цикла — это важно — для человека в первую очередь. Для компилятора, кстати, это тоже кое-какое значение имеет.

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

ЕМ>Я как раз никакой новой семантики не выдумывал, а использую обычную математическую. Если в математической задаче рассматривается N-мерный вектор (x₁; x₂; ...; x_n), и размерность эта конечна, то никого не заботит, принадлежат индексы элементов конечному или бесконечному множеству натуральных чисел, и как ведет себя множество таких чисел за пределами N.

То есть довод о том, что unsigned тут лучше, чем signed, потому, что все индексы больше 0, отзывается? Ведь никого не заботит поведение тапа за пределами отрезка [1, n]?

ЕМ>Это верно лишь в том случае, если unsigned соответствующей разрядности используется для математических расчетов внутри того самого кольца. В общей массе таких случаев крайне мало.
Во-первых, отучаемся говорить за всех. От задач зависит.
Во-вторых, тезис о том, что таких случаев очень мало, как раз и подтверждает мой тезис, что unsigned типы в большинстве случаев того, что ты назвал "общаяя масса" использовать противоестественно...

ЕМ>Опять-таки разумеется, если тупо использовать unsigned для решения произвольных математических задач. Только чем для этих произвольных задач будет лучше знаковая арифметика?
Тем, что границы диапазона, за которыми есть риск получить переполнение, дальше от обучно используемых диапазонов чисел...
Скажем, считая детей в классе, и даже в школе, не получится переполнить int.

E>>Почему тебе кажется, что разница между позицией первого и второго элемента -- это не -1, а 0xFFFFFFFFFFFFFFFF?
ЕМ>Я не понимаю, что такое "разница между позицией первого и второго элемента"? Дайте, пожалуйста, определение.

Ты же, вроде, считаешь, что позиции элементов естественно нумеровать положительными целыми? Ты првада не знаешь, что такое при этом разница? На сколько раньше или позже находится один, чем другой.
Для знаковых, которые ты в этом месте считаешь противоестественными, это будет означать просто разность индексов. Для беззнаковых -- определи аналог сам. На мой взгляд как не определяй, получается криво...

ЕМ>Как только мы переходим хоть к методу Ньютона, хоть к любому другому математическому методу, где для удобства используется нулевое значение в знаковой системе координат, мы перестаем оперировать с натуральными числами. В этом месте они должны быть преобразованы в знаковые целые. По-моему, это очевидно, и не требует отдельного разъяснения.

Не понятно, зачем использовать такие индексы, которые всё время надо преобразовывать к нормальным целым...

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

ЕМ>Для универсальных алгоритмов и контейнеров широкого назначения знаковая адресация вполне допустима. А вот для чего, например, argc в main имеет знаковый тип? В каких случаях он может становиться отрицательным?

В случае ошибки, например.

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

ЕМ>Вместо того, чтобы повторять очевидное, просто объясните, почему понятие натурального числа до сих пор не исчезло из математики,
Потому, что это популярное подмножество целых. Скажем почему чётные не исчезли, тебе надо объяснять? С моей точки зрения чётные и натуральные -- это примерно похожие по свойствам подмножества. Есть какие-то задачи, в которых эти подмножества востребованы, поэтому удобно говорить "где n -- натуральное", вместо "для любого целого n больше 0". И так же с "чётное" vs "остаток от деления на 2 равен 0"

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

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

ЕМ>Ну вот я читаю код, и вижу там "int NumberOfElements". Что я должен думать об этой переменной? Судя по названию, она содержит количество элементов чего-либо. Судя по типу, она может принимать отрицательные значения. Как это улучшает читабельность?

Ну, например так что разность двух количеств элементов -- знаковое число...

ЕМ>Исходно в C не было логического типа, но "для улучшения читабельности" считалось естественным вводить синоним boolean или bool. А для чего, собственно? Чего для этого не хватало в int?
Конкретно в было модно

#define BOOL int

но аналогом было бы

typedef int elements_count_t;

делать или, как я уже предлагал

typedef IntRange<1, INT_MAX>::Type elements_count_t;

ЕМ>Еще более показательная хрень случилась с массовым использованием signed char для символьных/строковых операций. Когда вышли за пределы ASCII, внезапно оказалось, что для проверки вхождения символа в кодовый интервал нельзя использовать вроде бы естественные сравнения. Хотя это было очевидно с самого начала.

Да, это пример более интересный. Потому, что это редкий случай, когда дополнительный старший бит важен. Тем не менее, обычно используют кодировку о -128 до 127... Но это так по историческим причинам.

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

V>1. целые int32_t не являются подмножеством математических целых, так как они закольцованы
Если мы всё ещё про стандарты С/С++, то они не закольцованы. переполнение знаковой арифметики -- UB...
Если же мы про конкретную какую-то реализацию, то знаковые отступают от целых при больших по модулю значениях, которых легко избегать. А беззнаковые в районе 0, что встречается сильно чаще...

V>2. вещественные float/double/... не являются подмножеством действительных математических целых, так как...
V>3. int32 не являются вложением int64 так как кольца у них разные (не в c++, в x86 например), формулировка "корректно вычисленная сумма" неуместна ибо является спецификой для int32.
V>4. вещественные float не являются вложением double...
V>5. ...

Если мы про х86 -- ассемблер, это один разговор, но мы же вроде как о С/С++? В этих языках знаковые целые не закольцованы...

V>Да это всё — разные модели. Они все "не являются". Оригинальный замес ТС был про то, что "в некоторых ситуациях даны все условия чтобы использовать беззнаковые, почему вместо них все продолжают использовать знаковые?". Кольца, переполнения, другие ужасы — это все выходит за рамки оригинального вопроса. Да и ладно что беззнаковые — кольца. В оригинальных условиях это никогда не выстрелит.
У меня претензия к логике ТС именно в его начальном посыле. Если нас ВООБЩЕ не интересует поведение используемого для представления индексов типа, за пределами валидных значений индексов, а так же производные понятия, вроде разности позиций, то не понятно, чем знаковые тут хуже или лучше беззнаковых. А если интересуют, то ЛОГИЧНЕЕ использовать знаковые, а не кольца по модулю вычетов...

V>Вот ты говоришь "корректно вычисленная сумма int32_t будет...". Что за "корректность" такая, кто сказал что должны применяться именно эти твои правила "корректности"?
Стандарт С/С++...

V>Правила этой темы задал ТС в своем стартовом сообщении. А ты тут придумываешь _другие_ правила. Конечно, по этим другим правилам получается что то другое. Те самые "числа, которые НЕ нужны".
Я обсуждаю языки С/С++ с принятыми в них правилами, а не абстрактные правила, которые кто-то для себя выдумал.
ТС же интересует не почему он так делает, а почему другие так не делают? На мой взгляд, если из общепринятых стандартных определений исходить, то то, что нравится ТС просто нелогично.
И он пока не смог пояснить, почему это лучше или логичнее.

Единственный случай интересный, который он пока привёл — это знаковые байты против беззнаковых.

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


EP>Всё нормально с выводом, да?
[...]
EP>Не делать итераций при N=0;

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

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

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

Что я могу тут несущественно. Существенно, что компилятор это не проверяет, в отличии от std::optional.

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

R>Конечно есть — сужение области видимости переменной цикла — это важно — для человека в первую очередь. Для компилятора, кстати, это тоже кое-какое значение имеет.
Для того чтоб сузить scope не надо кровь из носу заковыривать её в for.

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

R>>Конечно есть — сужение области видимости переменной цикла — это важно — для человека в первую очередь. Для компилятора, кстати, это тоже кое-какое значение имеет.
CC>Для того чтоб сузить scope не надо кровь из носу заковыривать её в for.

Ну это наиболее простой и естественный способ. Назови хоть одну причину, почему им нельзя воспользоваться?

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

R>Ну это наиболее простой и естественный способ. Назови хоть одну причину, почему им нельзя воспользоваться?
Чистота и понятность кода.
Не надо делать нежданчики. Как не надо устраивать митинг для того, что может быть простым email так и не надо заковыривать в for то, для чего достаточно while.
Код читают и правят много людей, разных людей, в разной степени затраханности. Не надо делать код сложнее просто чтобы сэкономить строчку другую.

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

CC>Чистота и понятность кода.
CC>Не надо делать нежданчики. Как не надо устраивать митинг для того, что может быть простым email
CC>Код читают и правят много людей, разных людей, в разной степени затраханности. Не надо делать код сложнее просто чтобы сэкономить строчку другую.

Субъективщина. Попытка абсолютизировать личные предпочтения.

CC>так и не надо заковыривать в for то, для чего достаточно while.

Во-первых, я изначально ничего против while и не имел, дискуссия изначально была не о while vs for;

Во-вторых, что значит "достаточно while"? Если ты покажешь более простой и естественный способ сузить область видимости переменной цикла, чем переход к for, то я готов принять твою точку зрения.

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

R>Субъективщина. Попытка абсолютизировать личные предпочтения.


R>Во-первых, я изначально ничего против while и не имел, дискуссия изначально была не о while vs for;
Эта подветка началась вот тут: Re[16]: Откуда эта лютая любовь к знаковым целым?

Автор: CreatorCray
Дата: 10.05.20

R>Во-вторых, что значит "достаточно while"? Если ты покажешь более простой и естественный способ сузить область видимости переменной цикла, чем переход к for

Смотря что ты считаешь за "простой и естественный".
Самый натуральный способ — определить новый scope через {}

for (size_t n = size(v); n--; )
 foo (n);

->

{
 size_t n = size(v);
 while (n--)
   foo (n);
}

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

R>>Субъективщина. Попытка абсолютизировать личные предпочтения.
CC>

Сильный аргумент. Это все?

R>>Во-первых, я изначально ничего против while и не имел, дискуссия изначально была не о while vs for;
CC>Эта подветка началась вот тут: Re[16]: Откуда эта лютая любовь к знаковым целым?

Автор: CreatorCray
Дата: 10.05.20

Что, и даже "Re[16]" тебя не смущает? "16", Карл! Нет, эта "подветка" началась вот откуда: Re[2]: Откуда эта лютая любовь к знаковым целым?

Автор: rg45
Дата: 05.05.20

. И то, против чего я высказывался, так это против этого нелепого аргумента:

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

А вовсе не о "while или for".

R>>Во-вторых, что значит "достаточно while"? Если ты покажешь более простой и естественный способ сузить область видимости переменной цикла, чем переход к for

CC>Смотря что ты считаешь за "простой и естественный".

Ах, вот как оказывается, "смотря что я считаю", то есть, частное мнение от абсолюй истины умеем отличать, все-таки. Ну, это обнадеживает

CC>Самый натуральный способ — определить новый scope через {}

CC>

CC>for (size_t n = size(v); n--; )
CC> foo (n);

->>

CC>{
CC> size_t n = size(v);
CC> while (n--)
CC>   foo (n);
CC>}
CC>

Ну я так и думал. Ну и ради чего это увеличение вложенности областей видимости? Хочешь я тебе расскажу, чем это закончится? Обязательно найдется долбодятел, который не поймет, для чего нужен этот блок и, либо удалит его нафиги, или, что еще хуже, начнет писать код прямо в нем. Это проще и естественноее по-твоему?

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

N>>>Наоборот, что оба граничных значения включены в набор.
EP>>Ну то есть ты действительно имеешь в виду стандартное значение closed, а не какое-то своё, а значит [n-1, 0] так?
EP>>n=1: [0, 0]
EP>>n=0: [-1, 0]
EP>>Зато смотри как стройно с while(n--): (n, 0]
N>Во! И вот тут мы пришли к тому, почему плохо с сишными беззнаковыми: [-1, 0, step=-1] — это просто пустое множество.

То есть твоё closed, действительно имеет какое-то своё значение, а не общепринятое

N>Вариант же while(n--) работает только в том случае, если n — количество элементов.

Ну и? В ядре Linux такой вариант встречается тыщу раз

N>Но тогда проблема возникает в другом — что это количество должно быть гарантированно не больше UINT_MAX, что легко нарушить, например, имея какое-то внешнее хранилище, или сдуру применив unsigned int вместо sizeof на 64-битке.

А это вообще к чему? Типа на знаковых ошибки диапазона исключены? Или если не использование while идиомы как-то спасает?

EP>>Ну так в C++ он half-open, как раз для того чтобы пустые диапазоны можно было определять: [first, first).
N>Не только. Ещё удобно их делить и суммировать: [0, 10) делится на [0, 6) и [6, 10).

Ну да, очень же удобно получилось. К чему ты начал закрытый диапазон тулить —

N>Проблема разворота такого диапазона отлично видна на странностях реализации reverse iterator.

Так покажи вариант лучше.

N>>>Ну и снова получаем уже известную проблему: надо перед циклом начать с n+1, чтобы в цикле работать с n. Это уже второй уровень наворота идиомы (первый — формат условия продолжения с пост-декрементом).
EP>>Да не нужно начинать с n+1, оно уже "готовое" — итератор .end() — уже указывает на один за последним элементом.
N>Это если у тебя n уже количество элементов. О чём я и говорю. А если это что-то другое — то идиоматичность ломается.

Идиома действительно для перебора n элементов вниз (n..0], с небольшой модификацией применима для итерации (last..first]. Это не универсальное решение всего на свете — с чем ты споришь-то?

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

EP>>Для полноты картины:
CC>Вот почему млять не написать while (i--) вместо for (; i--; ) ?

Здесь предпочту while. Также как и например предпочту while(true) чем for( ; ; ). Но это субъективно всё.

EP>>Ну я говорю всё время про while(n--), но можем конечно и вариант с for погрепать. Но суть от этого не меняет — применяется повсеместно.
CC>Претензии как раз к (for(...;i-- >0;...)

Если там for(size_t n = size(v); n--; ) — то вполне оправданно — ограничивается область видимости.
Для тех же целей в C++17 завезли init statements в if и switch. А while(init; cond) не завезли видимо как раз потому что уже есть for(init; cond; )

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

M>Ну вот какой добрый человек тему перенёс? Как мне теперь определить, что я читал, а что — нет?
RSDN@Home же!

Как вы в браузере читаете — вообще не представляю...

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

EP>>>Зато смотри как стройно с while(n--): (n, 0]
N>>Во! И вот тут мы пришли к тому, почему плохо с сишными беззнаковыми: [-1, 0, step=-1] — это просто пустое множество.
EP>То есть твоё closed, действительно имеет какое-то своё значение, а не общепринятое

Абсолютно стандартное. С чего вдруг иной вывод?

N>>Вариант же while(n--) работает только в том случае, если n — количество элементов.
EP>Ну и? В ядре Linux такой вариант встречается тыщу раз

Ну будем знать (в копилку бесполезностей)

N>>Но тогда проблема возникает в другом — что это количество должно быть гарантированно не больше UINT_MAX, что легко нарушить, например, имея какое-то внешнее хранилище, или сдуру применив unsigned int вместо sizeof на 64-битке.
EP>А это вообще к чему? Типа на знаковых ошибки диапазона исключены? Или если не использование while идиомы как-то спасает?

do-while — спасает и на эти случаи.

EP>>>Ну так в C++ он half-open, как раз для того чтобы пустые диапазоны можно было определять: [first, first).
N>>Не только. Ещё удобно их делить и суммировать: [0, 10) делится на [0, 6) и [6, 10).
EP>Ну да, очень же удобно получилось. К чему ты начал закрытый диапазон тулить —

Из того, что он естественно приходит из массы реальных случаев.

N>>Проблема разворота такого диапазона отлично видна на странностях реализации reverse iterator.
EP>Так покажи вариант лучше.

Уже много раз тут показывали, цикл с постпроверкой — самый простой и понятный.

N>>Это если у тебя n уже количество элементов. О чём я и говорю. А если это что-то другое — то идиоматичность ломается.
EP>Идиома действительно для перебора n элементов вниз (n..0], с небольшой модификацией применима для итерации (last..first]. Это не универсальное решение всего на свете — с чем ты споришь-то?

Именно в этом — ни с чем.

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

R>Ну это наиболее простой и естественный способ.

И это наверное из-за очень большой сложности, в if, начиная с определенного момента, тоже добавили такую возможность.

if(int i = somecode(); i < 0)
{
   //....
}

Но сейчас, конечно, опять будут говорить, что "дизайн говно".
Но раз так, то наверное не стоило ограничиваться только циклами.
Надо сразу уж объявить говном весь С++ и закончить на этом
Так, хотя бы, твои оппоненты будут последовательными в суждениях.

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

R>Сильный аргумент. Это все?
Лень буковки тратить на одно и то же. Ты скучный, как что — срываешься на "приблатняк".

R>Что, и даже "Re[16]" тебя не смущает? "16", Карл!
Пофигу. Подветка начинается там, где она начинается. Расти может из любого места.

R>

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

R>А вовсе не о "while или for".
А я начал подветку про "не надо for там где достаточно while"
Древовидная структура форума именно так и работает — в любой момент можно отбранчить.

CC>>Смотря что ты считаешь за "простой и естественный".
R>Ах, вот как оказывается, "смотря что я считаю", то есть, частное мнение от абсолюй истины умеем отличать, все-таки. Ну, это обнадеживает
Много эмоций и все не по делу. Сказать то что хотел?

R>Ну я так и думал. Ну и ради чего это увеличение вложенности областей видимости?
Уже было написано.

R> Хочешь я тебе расскажу, чем это закончится? Обязательно найдется долбодятел, который не поймет, для чего нужен этот блок и, либо удалит его нафиги, или, что еще хуже, начнет писать код прямо в нем.
Ты сам то понял что сказал?