Почему положительное меньше чем отрицательное?

почему отрицательное значение int больше чем положительное значение unsigned

0

Сообщение от Verevkin Оно жэж и так больше.

Еще раз:

Например

Язык С говорит, что (a < b) равно 0.

Что скажет ваш Паскаль? Пробуем:

Получаем тоже

Пробуем C++ с его std::cmp_less

Получаем

То есть std::cmp_less умудряется корректно обработать эту ситуацию.

0

Сообщение от TheCalligrapher Еще раз: Например

Короче, ну нахрен всё это, голова уже болит.
Будем считать, что тот, кто пытается сравнивать знаковое с беззнаковым, тот ССЗБ.

0

Сообщение от Verevkin голова уже болит

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

0

Сообщение от Алексей1153 чтоб сохранить голову, делай приведение вручную, чтобы не гадать или помнить, как поступит мсье компилятор

чтоб сохранить голову, я работаю на delphi. Он меня честно предупреждает, если я где-то лажаю.

0

Сообщение от Verevkin Он меня честно предупреждает, если я где-то лажаю.

Так и тут предупреждает, прямо конкретно тыча носом )))

0

Сообщение от мама Стифлера Так и тут предупреждает, прямо конкретно тыча носом )))

Не вижу. Хде?

0

0

мама Стифлера, а, так это не по умолчанию.

0

Verevkin, ну по умолчанию, флаги для компилятора не стоят, или стоят по дефолту какие то. В локальном компиляторе(IDE), ты устанавливаешь нужные тебе флаги и все. Короче настроил как тебе надо один раз и забыл. Как то так.

0

Сообщение от мама Стифлера Verevkin, ну по умолчанию, флаги для компилятора не стоят, или стоят по дефолту какие то. В локальном компиляторе(IDE), ты устанавливаешь нужные тебе флаги и все. Короче настроил как тебе надо один раз и забыл. Как то так.

0

TheCalligrapher, Я хотел объяснить как получилось, что отрицательное число при сравнении могло превратится в другое число, которое больше, и это не просто "ошибка сравнения" или Неопределённое Поведение(в конкретном компиляторе), а предсказуемое аппаратно-зависимое и уже стандартное представление чисел. А так да, в идеальном мире идей, спецификации важней, но такое поведение это скорее наследство аппаратных особенностей реализации ставнения и представления чисел в компьютерах, а спецификации просто описывая подобное поведение сохраняют предсказуемость уже написанных компиляторов и правильность уже написанных программ для них

Я бы просто советовал знать компилятор на котором пишешь, чем надеятся, что спецификации всегда помогут(часто помогают, но если что–то реализовано нелогично, то все равно приходится писать алтернативными методами(ну или менять компилятор, но идеальных может и не быть))

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

0

Вы маньяки-чикатилы.
Прекратите немедленно!

0

Сообщение от proger0x8654 Я хотел объяснить как получилось, что отрицательное число при сравнении могло превратится в другое число, которое больше, и это не просто "ошибка сравнения" или Неопределённое Поведение(в конкретном компиляторе), а предсказуемое аппаратно-зависимое и уже стандартное представление чисел.

Ну, во-первых, неопределенного поведения тут нет. Если бы тут было неопределенное поведение, то говорить было бы не о чем: никакое аппаратные особенности или представления чисел тут бы ситуацию не спасли.

Сообщение от proger0x8654 но такое поведение это скорее наследство аппаратных особенностей реализации ставнения и представления чисел в компьютерах, а спецификации просто описывая подобное поведение сохраняют предсказуемость уже написанных компиляторов и правильность уже написанных программ для них

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

В данном примере мы имеем дело с дилеммой, с которой сталкивается именно компилятор. И вариантов выхода из этой ситуации тут множество (я вижу навскидку как минимум четыре варианта). Никакого однозначного или просто предпочтительного варианта тут "компьютер" не предлагает. Выбор способа сравнения в таких ситуациях целиком и полностью лежит исключительно на компиляторе, т.е. именно на спецификации.

Ссылку на историю обсуждения этого вопроса в С я уже давал.

Сообщение от proger0x8654 Я бы просто советовал знать компилятор на котором пишешь

???

0

Verevkin, вроде обычная для раздела C++ размеренная беседа

0

TheCalligrapher,

Я бы просто советовал знать компилятор на котором пишешь ???

Я о том, что может попасться самописный компилятор, который решил, что он сделает сравнение "по математической логике", а не по спецификации, и в этом случае хорошо бы знать компилятор(лучше исходники понимать) и что у него ещё не реализовано по спецификации, а что "дополнительно реализованные особенности компилятора".
Вот http://programming-lang.com/ru... /j229.html тут пример того, что иногда компилятор думает больше, чем просто трансляция программы самым однозначным способом.
Да, решение такое: при сравнении разных типов писать их явное приведение, потому что правильно решить к какому из типов операндов делать приведение в общем случае не возможно решить.
Многие могут сказать что использование машинно-зависимых типов уменьшает переносимость кода(если почему-то 1 машинное слово == 9 битам), но вот на конкретной машине я думаю что писать просто int, long int, long long int, которые могут быть равны или не равны определённым машинным областям памяти или не меньше какой–то области памяти, а ещё long int может быть равен long long int если 32-битная машина ну это сложнее всё просчитать, чем писать uint8_t, uint16_t, uint32_t, uint64_t и int8_t, int16_t, int32_t, int64_t и float32_t, float64_t и программными float8_t, float16_t, fixed8_t, fixed16_t, fixed32_t, fixed64_t. Про то что int короче писать могу сказать, что сам пользуюсь define'ами u8,u16,u32,u64 и s8,s16,s32,s64 и fl8,fl16,fl32,fl64 и fx8,fx16,fx32,fx64 и мне стало удобнее и проще писать.

//Совет про то, что: не нравятся спецификации стандарта, не пиши на языке C или если компилятор языка C не исполняет спецификации языка C значит он не компилятор языка C пропадают когда вот TCC(Tiny C Compilier) может использовать точку входа как функцию _start() и не грузить из msvcrt.dll ещё набор встраиваемых при компиляции функций, а GCC(GNU C Compilier) пишет на _start() ошибку компиляции. Да и всё равно язык C это естественное развитие макросов ассемблера таких как invoke, поэтому моё мнение что самый низкоуровневый высокоуровневый язык программирования будет C–подобным.

Сообщение от TheCalligrapher Выбор способа сравнения в таких ситуациях целиком и полностью лежит исключительно на компиляторе, т.е. именно на спецификации.

В идеальном мире идей (реализация компилятора == реализации спецификации), но в реальности это чаще почти так, а то и немного почти так... а так, да, согласен с

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

, это так, я неточно написал, я хотел сказать, что язык C живёт на использовании кодов команд, которые реализованы аппаратно, а потому получилось, что отрицательное число записывается в [дополнительном коде].

0

Сообщение от proger0x8654 Я о том, что может попасться самописный компилятор, который решил, что он сделает сравнение "по математической логике", а не по спецификации, а не по спецификации, и в этом случае хорошо бы знать компилятор(лучше исходники понимать) и что у него ещё не реализовано по спецификации, а что "дополнительно реализованные особенности компилятора".

Не бывает.

Никакой С компилятор не станет реализовывать особенности, которые противоречат спецификации языка. Любая свобода реализации "особенностей" для корректного кода располагается в рамках разрешенных стандартом языка неопределенных, неспецифицированных или определяемых реализацией поведений. Выход за эти рамки - баги компилятора, которые будут исправляться с максимально возможной скоростью.

Сообщение от proger0x8654 Вот http://programming-lang.com/ru... /j229.html тут пример того, что иногда компилятор думает больше, чем просто трансляция программы самым однозначным способом.

Этот пример не имеет никакого отношения к языку С.

Сообщение от proger0x8654 //Совет про то, что: не нравятся спецификации стандарта, не пиши на языке C или если компилятор языка C не исполняет спецификации языка C значит он не компилятор языка C пропадают когда вот TCC(Tiny C Compilier) может использовать точку входа как функцию _start() и не грузить из msvcrt.dll ещё набор встраиваемых при компиляции функций, а GCC(GNU C Compilier) пишет на _start() ошибку компиляции.

Пример совершенно мимо кассы. _start - зарезервированный идентификатор.

Сообщение от proger0x8654 В идеальном мире идей (реализация компилятора == реализации спецификации), но в реальности это чаще почти так, а то и немного почти так... а так, да, согласен с

См. выше.

0

TheCalligrapher,

Сообщение от TheCalligrapher Не бывает. Никакой С компилятор не станет реализовывать особенности, которые противоречат спецификации языка.

А если он самописный и скачанный от куда–то из интернета?
Я просто не могу поверить в то, что все в мире, кто писал C–подобный компилятор будут желать реализовать все спецификации точно.
Да и

Примечательным примером является язык Си, который приобрёл популярность без формальной спецификации, а был описан вместо этого в части книги, «Язык программирования Си» (1978 г.), и был формально стандартизован намного позже в ANSI C (1989 г.);

из https://ru.wikipedia.org/wiki/... ммирования, а потому он мог быть написан раньше ANSI C.

Сообщение от TheCalligrapher _start - зарезервированный идентификатор.

ну, зарезервировать(ну то есть где–то в include <???????.h> объявить) и я могу 50 разных переменных и прототипов функций с разными префиксами и простыми названиями, только вот если в TCC это можно использовать то в GCC у меня не получилось(ошибка), я был бы рад, если GCC это зарезервированное слово делало мне пользу также как TCC.

Сообщение от TheCalligrapher Этот пример не имеет никакого отношения к языку С.

Да, признаю, это просто пример разных решений вопроса приведения типа в разных компиляторах.

Добавлено через 2 минуты

Сообщение от proger0x8654 только вот если в TCC это можно использовать то в GCC у меня не получилось(ошибка), я был бы рад, если GCC это зарезервированное слово делало мне пользу также как TCC.

— это я про _start() {}

0

Сообщение от proger0x8654 TheCalligrapher, А если он самописный и скачанный от куда–то из интернета?

Вопрос содержит в себе примерно столько же смысла как и "А если он компилятор Паскаля?"

Если компилятор намеренно не соответствует спецификации языка С, то никто, никогда и нигде не будет называть его компилятором языка С.

Сообщение от proger0x8654 Я просто не могу поверить в то, что все в мире, кто писал C–подобный компилятор будут желать реализовать все спецификации точно.

Я не знаю, что в данном случае имеется в виду под "точно". Но:

Если компилятор намеренно не соответствует спецификации языка С, то никто, никогда и нигде не будет называть его компилятором языка С.

0

TheCalligrapher, как я уже писал язык C до некоторого времяни не был стандартизован(а может я старой школы и пишу на древнем компиляторе языка C, который не поддерживает ANSI C), ну а то насколько код программы C–шный можно долго думать(а если там > 50% )
Да, частично согласен, что

Сообщение от TheCalligrapher Если компилятор намеренно не соответствует спецификации языка С, то никто, никогда и нигде не будет называть его компилятором языка С.

, но если он(компилятор) старых времён(до стандартизации) то говорить, что это уже "НЕ язык C", тоже я думаю грубо.

0