Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Да что ж это такое-то, а? Вы хоть раз попробуйте понять то, о чем я тут талдычу уже который раз. А талдычу я об исходных данных для вычислений, а не о решениях (результатах). У математиков были все основания обобщать решения, поскольку эти решения, по сути своей, не обязаны быть ни натуральными, ни целыми, ни даже рациональными. А у программистов нет оснований обобщать входные данные, выраженные в натуральных числах, кроме стремления сэкономить на приведениях типов.
Ты вообще ничего не писал по сути, просто какие-то возмущения. Как бы намекая, что все, кто не использует беззнаковые везде, где только можно, ммм, недалёкого ума люди. Типа польза от беззнаковости сама по себе очевидна — что явно не так. По факту беззнаковость вообще малополезна, но с кучей побочных эффектов.
Ну и не понятно, что такое "входные данные", которые оторваны от вычислений. Типа поставил unsigned и ничего некорректного к тебе дальше не пройдёт? Да вполне пройдёт. Мы же вообще не призываем отказываться от беззнаковых, просто перечисляем те случаи, где они по смыслу могли бы быть, но на практике малополезны или даже вредны и требуют больше внимания и проверок.
Здравствуйте, netch80, Вы писали:
TB>>>Ты на беззнаках даже тупо от ЭН до нуля проитерироваться не можешь без дополнительного бубна. E>>А как же "оператор стремления к нулю"? E>>
E>>size_t i = n;
E>>while(i-->0) {
E>> // Тут что-то делаем с n-1, n-2, ..., 1, 0
E>>}
E>>
N>С этим оператором для N-битного числа ты не сможешь сделать, чтобы первая итерация была 2**N-1 (например, в 32-битке нельзя сделать, чтобы первая итерация была для i == 0xFFFF_FFFF): тебе придётся зайти с i == 0, и while() немедленно отвергнет (а выйдя ты как раз 0xFFFF_FFFF и найдёшь в i, но будет поздно). N>А иногда бывает и такая потребность, приходится учитывать. Так что нет тут полного счастья без постпроверки.
Ну пост проверка:
std::uint32_t i = 0xFFFFFFFF;
do
{
// Тут что-то делаем с n, n-1, n-2, ..., 1, 0
}while(i-->0);
Здравствуйте, Nuzhny, Вы писали:
N>Ты вообще ничего не писал по сути, просто какие-то возмущения.
Если не читать — конечно, ничего и не найти.
N>Как бы намекая, что все, кто не использует беззнаковые везде, где только можно, ммм, недалёкого ума люди.
А вот такого я не писал.
N>Типа польза от беззнаковости сама по себе очевидна — что явно не так.
Я писал, что очевидна польза от типа, отражающего суть представленного значения. Примерно так же, как польза от bool, хотя долгое время вполне обходились int, и от nullptr, хотя годится и обычный нуль.
N>Ну и не понятно, что такое "входные данные", которые оторваны от вычислений.
Они не "оторваны", они просто есть.
N>Типа поставил unsigned и ничего некорректного к тебе дальше не пройдёт? Да вполне пройдёт.
Спасибо, КО.
N>Мы же вообще не призываем отказываться от беззнаковых, просто перечисляем те случаи, где они по смыслу могли бы быть, но на практике малополезны или даже вредны и требуют больше внимания и проверок.
Значит, мне показалось, что все, кто здесь неоднократно высказался в пользу широкого применения значений со знаком, согласны признать пользу беззнаковых чуть ли не исключительно за size_t.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Значит, мне показалось, что все, кто здесь неоднократно высказался в пользу широкого применения значений со знаком, согласны признать пользу беззнаковых чуть ли не исключительно за size_t.
Только там, где реально нужны битовые или модульные операции. И всё.
В СТЛ от них пользы нет, только вред.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Значит, мне показалось, что все, кто здесь неоднократно высказался в пользу широкого применения значений со знаком, согласны признать пользу беззнаковых чуть ли не исключительно за size_t.
Ну тут очень надвое.
С одной стороны, я думаю, что они таки нужны, но далеко не так широко, как тебе кажется. Практически все их применения это интерфейс с чем-то, где именно полная разрядность соответствующего размера действительно необходима. Но кроме передачи адреса как числа я и не нахожу универсального примера.
Ещё как промежуточные сущности длинной арифметики — вот в GMP, mpz это оболочка вокруг mpn, и все операции с mpz переводятся в операции с mpn.
С другой стороны, если с ними проблема — я вообще и в случае size_t не очень вижу смысла, наблюдая, например, что в Java обходятся без беззнаковых вообще И размеры там тоже все знаковые.
(Точнее, начиная с 8ки там есть отдельные методы для арифметических операций, кому нужно — но почти всё без них работает не хуже. Ещё там есть устарелость, что много таких размеров не long, а int. Но и это очень редко когда кому что-то ломает.)
Аналогично, C# CLS — живёт же без беззнаковых. В Фортране нету беззнаковых. Наверно, есть ещё примеры.
Здравствуйте, B0FEE664, Вы писали:
N>>С этим оператором для N-битного числа ты не сможешь сделать, чтобы первая итерация была 2**N-1 (например, в 32-битке нельзя сделать, чтобы первая итерация была для i == 0xFFFF_FFFF): тебе придётся зайти с i == 0, и while() немедленно отвергнет (а выйдя ты как раз 0xFFFF_FFFF и найдёшь в i, но будет поздно). N>>А иногда бывает и такая потребность, приходится учитывать. Так что нет тут полного счастья без постпроверки.
BFE>Ну пост проверка: BFE>
BFE>std::uint32_t i = 0xFFFFFFFF;
BFE>do
BFE>{
BFE> // Тут что-то делаем с n, n-1, n-2, ..., 1, 0
BFE>}while(i-->0);
BFE>
BFE>И чо?
Цитирую ещё раз:
И то, что не предпроверка, как у предыдущего оратора. Собственно, и всё
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я писал, что очевидна польза от типа, отражающего суть представленного значения. Примерно так же, как польза от bool, хотя долгое время вполне обходились int, и от nullptr, хотя годится и обычный нуль.
Тогда почему ты рассматриваешь вопрос так узко?
У тебя ведь в большинстве случаев нет реального типа, которому бы требовалось представлять именно, например, значения от 0 до 4_294_967_295.
Где-то оно будет от 0 до 9, где-то от 0 до 999999, а где-то подсчитать всех людей на Земле — в uint32_t не влезет... а ты их всех под одну гребёнку.
Вот у тебя возраст человека — почему unsigned? Должен быть, как в Ada, type age = new integer 0..999 (да, я оптимист)
А ты решил, что у тебя всё влезет в unsigned int.
Как писал Реймонд, вопросы типа "как с помощью X сделать Y?" уже предполагают, что надо делать через X, когда на самом деле может быть лучше и полезнее сделать Y как-то иначе.
Целые типы низкоуровневого языка вроде C — отражают возможности железа, а не потребности задачи. В решении на высокоуровневом языке ты описываешь типы со множествами значений, а за тебя уже делают реализацию. И только когда этого недостаточно или ты грубо ломаешь зачем-то это (зачем?) — появляются конкретные типы с конкретной знаковостью.
Вот в случае цикла компилятор может решить, например, что переменная цикла будет uint32_t, но для краевого условия он её сделает знаковой, и решит, достаточно ли ему int32_t или нужна int33_t. И если ему нужна int33_t — он её смоделирует любым подходящим образом. А может, он перенесёт проверку до декремента... уже его дело.
Здравствуйте, Евгений Музыченко, Вы писали:
N>>Вот из подобной логики математики от Пифагора и аль-Хорезми и вплоть до Кардано вынуждены были расписывать решения уравнений типа x**2+p*x+q=0 на все 4 случая (а для кубического — уже на 8). А потом пришло следующее поколение с Виетой и упростило весь этот бардакомаразм, введя отрицательные числа.
ЕМ>Да что ж это такое-то, а? Вы хоть раз попробуйте понять то, о чем я тут талдычу уже который раз. А талдычу я об исходных данных для вычислений, а не о решениях (результатах). У математиков были все основания обобщать решения, поскольку эти решения, по сути своей, не обязаны быть ни натуральными, ни целыми, ни даже рациональными. А у программистов нет оснований обобщать входные данные, выраженные в натуральных числах, кроме стремления сэкономить на приведениях типов.
См. моё письмо только что про высокоуровневые подходы.
Здравствуйте, Евгений Музыченко, Вы писали:
N>>Именно в struct tm можно было бы хранить и без знака, но зачем, если там значения гарантированно меньше соответствующего максимума даже в исходной 16-битке?
ЕМ>Да просто затем, что эти значения по своей сути не имеют знака.
И ещё раз намекну на диапазоны значений.
Пусть есть два типа, оба из которых могут использоваться для машинного представления, а целевой диапазон приложения — от 1 до 31 (mday_t).
У первого типа диапазон значений -32768..32767, у второго 0..65535.
Почему для тебя беззнаковость номера дня важнее остальных факторов?
N>>Но, как только начинается вопрос про то, что даты надо вычитать, уже приходится переводить к знаку (об этом тебе уже написали рядом). Ну и зачем эти лишние конверсии? ЕМ>А если даты нужно делить, чтобы, например, вычислить среднее количество дней, которое занимали некие процессы? Давайте уж сразу хранить их в double, сэкономим на конверсиях.
И это вполне возможно. Юлианский день, в плавучке — достаточно точный метод задания времени. Но тут начинаются проблемы округления, это уже неудобно. Вот unixtime в микросекундах со знаком — достаточно дёшево и защищено от подобных проблем.
Здравствуйте, netch80, Вы писали:
N>С другой стороны, если с ними проблема — я вообще и в случае size_t не очень вижу смысла, наблюдая, например, что в Java обходятся без беззнаковых вообще И размеры там тоже все знаковые.
Java, по определению, не имеет прямого выхода на реальное (для программного кода) адресное пространство. Там просто нельзя работать с непрерывными объемами памяти, при которых может сказаться знаковость размера блока.
N>Аналогично, C# CLS — живёт же без беззнаковых. В Фортране нету беззнаковых.
А еще в Фортране можно изменить константу, переданную параметром функции. Как будем выбирать, с чего достойно брать пример, а с чего — нет?
Здравствуйте, netch80, Вы писали:
N>У тебя ведь в большинстве случаев нет реального типа, которому бы требовалось представлять именно, например, значения от 0 до 4_294_967_295.
Когда у меня есть значения, у которых по смыслу не может быть знака, и язык предоставляет типы для хранения таких значений — мне кажется очено логичным использовать именно их. Точно так же, как для хранения двух противоположных по смыслу значений логично использовать bool, а не int/uint, хотя физически bool хранит минимум 256.
N>Вот у тебя возраст человека — почему unsigned? Должен быть, как в Ada, type age = new integer 0..999 (да, я оптимист)
С Ada я никогда не имел дела, а когда в детстве впервые познакомился с Pascal, идея отрезков типов меня очень впечатлила. И в C++ она пришлась бы очень кстати.
N>А ты решил, что у тебя всё влезет в unsigned int.
За неимением гербовой...
N>Целые типы низкоуровневого языка вроде C — отражают возможности железа, а не потребности задачи. В решении на высокоуровневом языке ты описываешь типы со множествами значений, а за тебя уже делают реализацию.
Так я за то и люблю C++, что он [пока] позволяет удачно совмещать высокоуровневые концепции с низкоуровневой реализацией. И значения -16..+15 можно удобно положить рядом с 0..31 в битовые поля.
N>Вот в случае цикла компилятор может решить, например, что переменная цикла будет uint32_t, но для краевого условия он её сделает знаковой
Когда я поручаю создание переменной компилятору — его дело, как ее реализовать.
Здравствуйте, netch80, Вы писали:
N>Почему для тебя беззнаковость номера дня важнее остальных факторов?
Каких "всех"? Здесь пока озвучивались только монотонность при переходе через нуль, спецзначения вроде -1, и экономия на преобразованиях. Циклы с декрементом до нуля включительно я использую крайне редко, для спецзначений использую UINT_MAX и соседние, и добавить несколько преобразований, даже в виде static_cast вместо int (), меня не ломает.
N>>>Но, как только начинается вопрос про то, что даты надо вычитать, уже приходится переводить к знаку (об этом тебе уже написали рядом). Ну и зачем эти лишние конверсии? ЕМ>>А если даты нужно делить, чтобы, например, вычислить среднее количество дней, которое занимали некие процессы? Давайте уж сразу хранить их в double, сэкономим на конверсиях.
N>И это вполне возможно. Юлианский день, в плавучке — достаточно точный метод задания времени. Но тут начинаются проблемы округления, это уже неудобно. Вот unixtime в микросекундах со знаком — достаточно дёшево и защищено от подобных проблем.
Знак-то там зачем? Я вот очень часто пользуюсь виндовой GetTickCount, и ни разу не приходилось преобразовывать результат к знаковому типу. Запомнил время при старте цикла или на последней итерации, на очередной итерации вычел его из нового значения, получил истекший интервал. "Заворот" при переполнении обрабатывается естественным образом, автоматически. Что я все эти годы делал не так?
Здравствуйте, Евгений Музыченко, Вы писали:
N>>С другой стороны, если с ними проблема — я вообще и в случае size_t не очень вижу смысла, наблюдая, например, что в Java обходятся без беззнаковых вообще И размеры там тоже все знаковые. ЕМ>Java, по определению, не имеет прямого выхода на реальное (для программного кода) адресное пространство. Там просто нельзя работать с непрерывными объемами памяти, при которых может сказаться знаковость размера блока.
Прямого выхода — нет. При наличии адекватной прослойки — можно. Один из проектов, что я наблюдал, делал так. Другой вопрос, что за счёт организации адресного пространства процесса там не было отрицательных чисел как адресов — ну так могут быть платформы, где и это реализуется.
N>>Аналогично, C# CLS — живёт же без беззнаковых. В Фортране нету беззнаковых.
ЕМ>А еще в Фортране можно изменить константу, переданную параметром функции.
Это никогда не требовалось стандартом и было спецификой древних реализаций. Сейчас ты такого и не воспроизведёшь — будет нарушение защиты памяти, я проверил.
EM> Как будем выбирать, с чего достойно брать пример, а с чего — нет?
Уж точно не на древних примерах, не относящихся к делу — а на основании всей совокупности факторов.
Здравствуйте, Евгений Музыченко, Вы писали:
N>>У тебя ведь в большинстве случаев нет реального типа, которому бы требовалось представлять именно, например, значения от 0 до 4_294_967_295.
ЕМ>Когда у меня есть значения, у которых по смыслу не может быть знака, и язык предоставляет типы для хранения таких значений — мне кажется очено логичным использовать именно их.
Вот именно это "очень логично" не воспроизводится у меня или остальных твоих оппонентов. Почему для тебя расширить какой-нибудь 1-31 в сторону до 65335 нормально, а в противоположную, с переходом через ноль — нет? Я вижу в нём больше логики хотя бы потому, что расширение более равномерно с обеих сторон. Ну а про арифметику на днях месяца тут уже неоднократно говорили.
EM> Точно так же, как для хранения двух противоположных по смыслу значений логично использовать bool, а не int/uint, хотя физически bool хранит минимум 256.
Ты неправ по факту. bool хранит два значения. Никто не обязан в конкретной реализации передавать его в байте. Вполне законно его, например, использовать через предикатный регистр стиля Itanium, который шириной в 1 бит. vector<bool> по стандарту хранит однобитовые значения.
N>>Вот у тебя возраст человека — почему unsigned? Должен быть, как в Ada, type age = new integer 0..999 (да, я оптимист) ЕМ>С Ada я никогда не имел дела, а когда в детстве впервые познакомился с Pascal, идея отрезков типов меня очень впечатлила. И в C++ она пришлась бы очень кстати.
Ну тогда знай, что в Ada модель с форсированием проверки попадания в диапазон — то есть в этом случае присвоение значения за пределами вызывает исключение.
N>>А ты решил, что у тебя всё влезет в unsigned int. ЕМ>За неимением гербовой...
?
N>>Целые типы низкоуровневого языка вроде C — отражают возможности железа, а не потребности задачи. В решении на высокоуровневом языке ты описываешь типы со множествами значений, а за тебя уже делают реализацию. ЕМ>Так я за то и люблю C++, что он [пока] позволяет удачно совмещать высокоуровневые концепции с низкоуровневой реализацией. И значения -16..+15 можно удобно положить рядом с 0..31 в битовые поля.
Если "удачно" это почти не контролируемо и с кучей подводных граблей... ню ню.
N>>Вот в случае цикла компилятор может решить, например, что переменная цикла будет uint32_t, но для краевого условия он её сделает знаковой ЕМ>Когда я поручаю создание переменной компилятору — его дело, как ее реализовать.
Не не, ты ж тип уже задал. Ты не можешь не задать тип.
Здравствуйте, Евгений Музыченко, Вы писали:
N>>Почему для тебя беззнаковость номера дня важнее остальных факторов?
ЕМ>Каких "всех"? Здесь пока озвучивались только монотонность при переходе через нуль, спецзначения вроде -1, и экономия на преобразованиях.
Ну вот это оно и есть. Вполне достаточно, чтобы использовать равномерное расширение, где доступно.
EM> Циклы с декрементом до нуля включительно я использую крайне редко, EM> для спецзначений использую UINT_MAX и соседние,
Ну а почему собственно такое загромождение кода и понятий (надо ещё постоянно помнить, что это за UINT_MAX) вместо -1, -2, ... ? Большинству тут отрицательные таки проще (хотя ещё лучше, конечно, когда они именованные константы).
EM> и добавить несколько преобразований, даже в виде static_cast вместо int (), меня не ломает.
Ну а многим не понравится загромождение текста.
N>>И это вполне возможно. Юлианский день, в плавучке — достаточно точный метод задания времени. Но тут начинаются проблемы округления, это уже неудобно. Вот unixtime в микросекундах со знаком — достаточно дёшево и защищено от подобных проблем.
ЕМ>Знак-то там зачем?
Для разностей.
EM> Я вот очень часто пользуюсь виндовой GetTickCount, и ни разу не приходилось преобразовывать результат к знаковому типу. Запомнил время при старте цикла или на последней итерации, на очередной итерации вычел его из нового значения, получил истекший интервал. "Заворот" при переполнении обрабатывается естественным образом, автоматически. Что я все эти годы делал не так?
Тики по GetTickCount специально рассчитаны на такой режим. Но у тебя это работает потому, что в C/C++ unsigned уже гарантированно сделано арифметикой по модулю.
В Ada это отдельный тип чисел: "type counter32 = modulo 2**32" и т.п. (модуль не обязан быть степенью двойки). Вот там, да, штатно такая арифметика (без защиты на заворот).
А знаковые разности времени важны, например, при сборе статистики по работе цикла событий (первое, что вспомнилось навскидку). Так бы пришлось знак выносить отдельно.
Или где-то у меня по аналогичным принципам регулируется запуск очереди заданий в зависимости от нагрузки, там тоже сплошные знаковые в формулах.
Здравствуйте, Marty, Вы писали:
ЕМ>>Даже во многих современных программах на C++ часто вижу int/short/long там, где по смыслу должно быть беззнаковое целое. M>Писать зело больше
Ой, да ладно. Это просто отмазка.
На самом деле можно даже извратиться как нибудь так:
defines.h:
typedef unsigned int counter;
или
#define counter unsigned int;
Здравствуйте, Erop, Вы писали:
E>Если же коротко повторить, что бы не обсуждать в нескольких подветках, то E>unsigned -- это кольцо по модулю вычетов известных степеней 2 E>signed -- это отрезок целых с доопределением операции деления на случай некратных чисел при помощи целочисленного деления и взятия остатка. E>Соответственно, если мы где-то можем рассуждать о коде, игнорируя разрядность целых, то есть как о числах в математическом смысле, то этот код более читабельный и высокоуровневый, чем такой, где мы не можем игнорировать разрядность переменных. E>И в этом смысле семантика индексов -- это тоже отрезок целого ряда, просто другой. И создавать его поверх отрезка целых [INT_MIN, INT_MAX] намного естественнее, чем над кольцом по модулей вычетов.
Не не не, Дэвид Блэйн, меня ты не проведёшь.
Там где проявляется закольцованность у безнаковых, у знаковых вообще случается undefined behaviour (речь же о C++?). Причём для индексов случается чаще, в силу меньшего положительного диапазона.
В одном случае имеем чёткую модель кольца, а в другом даже магмы нет, ибо операции не замкнуты
Здравствуйте, T4r4sB, Вы писали:
TB>>>Ты на беззнаках даже тупо от ЭН до нуля проитерироваться не можешь без дополнительного бубна. R>>А в чем проблема? TB>i--, заменяющее сразу два блока из заголовка for? Мы вам перезвоним, ога.
while(n--) — стандартная идиома, встречается повсеместно.
TB>>>Ты на беззнаках даже тупо от ЭН до нуля проитерироваться не можешь без дополнительного бубна.
Следуя таким же рассуждениям, можно прийти к "на знаковых нормально корень из отрицательных не извлечь, надо переходить к гауссовым числам"
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>while(n--) — стандартная идиома, встречается повсеместно.
Да, но тогда и надо писать цикл вайлом, а не фором.
И это всё равно не отменяет того факта, что такое решение — костыль.
EP>Следуя таким же рассуждениям, можно прийти к "на знаковых нормально корень из отрицательных не извлечь, надо переходить к гауссовым числам"
Дык и правда не извлечь. Но это редко когда надо.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
