Здравствуйте, Homunculus, Вы писали:
H>для этого я лично использую «-1». И если переменная равна ему, то значит значение невалидное. Такая штука с unsigned не проканает, если не вводить всякие magic digits конечно.
Чем "-1" менее magic, нежели "65535" или "uint_max"?
V>>Два наисложнейших бубена, оба без UB:
V>> for(unsigned u{5+1}; u-->0; ) V>> cout << u << endl;
TB>Использование второго выражение в заголовке цикла не по назначению
Какой то каргокульт головы, имхо.
V>> for(unsigned u{5}; u<=5; --u) V>> cout << u << endl;
TB>Противоестественная семантика условия выхода. Да, я знаю, как работает переполнение для беззнаковых. Всё равно это лажа. К тому же она не проканает, когда надо проитерироваться от ЭН до ИКС, где ИКС это число 0 нуля включительно.
TB>Это и есть бубны.
Ну так я ж так и говорю: два наисложнейших бубена.
Здравствуйте, T4r4sB, Вы писали:
TB>Ну допустим, что i++ в середине выражения ещё можно считать стандартной практикой, если i больше нигде в выражении не используется.
Ну вот и чудненько, значит, если написать так:
for (size_t i = std::size(arr); i-- != 0;) {
// . . .
}
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, T4r4sB, Вы писали:
TB>>От нуля до N-1. На беззнаковых такой перебор записывается довольно неестественно.
ЕМ>"for (uint i = 0; i < N; ++i)". В каком месте неестественность?
Там --i. То есть число уменьшаем до тех пор, пока оно не станет очень большим. Неестественно.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Евгений Музыченко, Вы писали:
SVZ>>Индекс в массиве это полноценная сущность БД. Используется вместо указателей. SVZ>>В этом случае отрицательные значения используются для обозначения невалидных объектов (у нас это -1) и для каких-нибудь специальных констант.
ЕМ>По-хорошему, все эти специальные константы неплохо бы именовать.
Дык!
enum { NONE = -1, DEAD = -2 };
ЕМ>А какая разница, именовать -1 или uint_max?
В коде без разницы, а под отладчиком очень большая разница — увидеть "-2" и "-1" или "4294967294" и "4294967295".
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Операции, в которых участвуют исключительно знаковые аргументы, производятся по правилам обычной школьной арифметики (mod 2^31 держим в уме, конечно) PD>Операции, в которых используются исключительно беззнаковые аргументы, хороши, пока дело ограничивается арифметикой на уровне начальной школы — до того момента, когда в школе начинают изучать отрицательные числа. Вопрос о том, можно ли от 1 отнять 2, и что при этом будет, блокируется Марией Ивановной со словами "об этом вам расскажут в 5 классе"
Подобные рассуждения хороши для языков совсем уж высокого уровня, где разрядность значения всегда остается где-то на заднем плане. В C/C++ она является одним из ключевых признаков типа. Если программист недостаточно хорошо понимает особенности представления, C/C++ однозначно не для него.
Здравствуйте, kov_serg, Вы писали:
_>Зачем использовать без знаковое целое где можно использовть обычный int или very long long. Только ради экономии 1-го бита?
Спросите математиков, зачем они делят числа на целые и натуральные, а не обходятся только целыми. Универсальнее же.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Операции, в которых участвуют исключительно знаковые аргументы, производятся по правилам обычной школьной арифметики (mod 2^31 держим в уме, конечно)
C++ это не школа , в нем mod 2^31 не работает, наступает UB и все летит в ад. Вот, например, адская хэш-функция, внутри которой используются знаковые переменные, тут, искать по слову hash_code. Ужос.
Здравствуйте, rg45, Вы писали:
R>Как только я их выдержал, требования тут же изменились. Ну просто упрямствуешь же.
Требование не использовать побочные эффекты во втором выражении было всегда, я это не скрывал. Ах да, в одном сообщении я это забыл скопировать, чем ты и воспользовался. Классическое правило тролля — поймать оппонента на неполной копировании контекста из сообщения в сообщение.
TB>>Вообще то, как яро вы отстаиваете подобную запись, и есть аргумент против беззнаковых.
R>Странная логика. А то, как яро ты оспариваешь эту запись является аргументом против знаковых что ли?
Я отстаиваю классическую запись — инициализация — условия — процедура итерации. Они ни у кого не вызвыает вопросов. То, что ты вынужден извращаться, использовать for по-другому — это и есть аргумент.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, rg45, Вы писали:
R>операция индексирования применима не только к массивам, но и указателям. Ведь, согласно стандарту, операция индексирования — это просто комбинация опраций сложения указателя и числа с последующим разыменованием.
*(p + i), *(i + p), p[i], i[p]
— все это равнозначные выражения и индекс вполне может быть отрицательным.
Индекс массива в C/C++ не может быть отрицательным — это следует из определения массива. То, что подобные операции могут приводить к отрицательным смещениям, ничем не отличается от технической возможности обратиться к элементу с очень большим индексом, чтобы за счет переполнения попасть раньше начала массива. Тут просто нужно различать техническую возможность получить какой-то результат, и смысл применямой операции.
Постфиксный инкремент, походу, отменять пора, как "кулхацкерский"?
TB>Ах да, в одном сообщении я это забыл скопировать, чем ты и воспользовался. Классическое правило тролля — поймать оппонента на неполной копировании контекста из сообщения в сообщение.
Ах да, в показаниях путаешься ты, а тролль — я. Ну, ожидаемо, в принципе.
TB>Я отстаиваю классическую запись — инициализация — условия — процедура итерации. Они ни у кого не вызвыает вопросов. То, что ты вынужден извращаться, использовать for по-другому — это и есть аргумент.
Классическая запись четко и яяно описана в стандарте языка. Все остальное — твои личные фантазии.
Здравствуйте, Homunculus, Вы писали:
ЕМ>>Чем "-1" менее magic, нежели "65535" или "uint_max"?
H>Ну например тем, что при инкременте мы в любом случае получим валидное. И невалидное при инкременте становится валидным.
Хм. Мне всегда казалось, что использовать "особые" значения в общих операциях, не отсекая их проверками, допустимо только в тех редких случаях, когда эти "особые" значения удачно укладываются в смысл переменной и логику операций с нею. В большинстве случаев такого не получается, и допустить спецзначения до общих операций — это заложить хорошую такую мину на будущее.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Индекс массива в C/C++ не может быть отрицательным — это следует из определения массива. То, что подобные операции могут приводить к отрицательным смещениям, ничем не отличается от технической возможности обратиться к элементу с очень большим индексом, чтобы за счет переполнения попасть раньше начала массива. Тут просто нужно различать техническую возможность получить какой-то результат, и смысл применямой операции.
Мы сейчас говорим про индексы. А индексы применимы не только к массивам.
Здравствуйте, T4r4sB, Вы писали:
TB>>>От нуля до N-1. На беззнаковых такой перебор записывается довольно неестественно.
ЕМ>>"for (uint i = 0; i < N; ++i)". В каком месте неестественность?
TB>Там --i. То есть число уменьшаем до тех пор, пока оно не станет очень большим. Неестественно.
Здравствуйте, rg45, Вы писали:
R>Ах да, в показаниях путаешься ты, а тролль — я. Ну, ожидаемо, в принципе.
В каких показаниях я путаюсь?
1. Постфиксный инкремент надо применять крайне осторожно.
2. Побочные эффекты во втором выражении в заголовке for — кулхацкерство.
Где я это отрицал? Ты развлекаешься что ли там?
R>Классическая запись четко и яяно описана в стандарте языка. Все остальное — твои личные фантазии.
Повторяю: синтаксическая корректность ещё не показатель приемлемости кода.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Ну смотри, пример. Массив (вектор который, а не лист) и индекс некоего "выбранного" элемента. Это индекс. Он не может быть отрицательным. Так ведь? Но штука в том, что у нас может не быть вообще выбранных элементов. Какое значение тогда должен принять этот индекс? 65535? uint_max? Мне это кажется нелогичным и некрасивым. По мне так гораздо красивее в этом случае назначать ему "-1"
.
, в нем mod 2^31 не работает, наступает UB и все летит в ад. Вот, например, адская хэш-функция, внутри которой используются знаковые переменные, тут, искать по слову hash_code. Ужос.
