- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
int reverse(int x) {
long int a=x;
if (a<10 && a>-1) return a;
int kol=2,k=1,i;
long int sum=0;
if (a<0) {
k=-1;
a=(-1)*a;
}
long int num=a;
while (true){
if ((num/=10)>9)
kol++;
else break;
}
for (i=0;i<kol;i++){
sum=10*sum+a%10;
a/=10;
}
return sum*k;
}
Follow us!
Ну привет, UB.
Эээ. NEG
>потому что -a делается через ~a+1
Да неужели?
А обратный код применяется только на экзотических платформах (типа Unisys ClearPath, см. ниже).
На более распространённых процессорах 1111=-1. Хотя возможность того, что когда-нибудь придётся писать под Unisys, упускать тоже не сто́ит.
и каким образом там 1111 будет -1?
Выручайте! Придумайте, где могут понадобиться четырёхбитовые знаковые числа.
0000 = 0, 0100 = 1, 0101 = 2, 0110 = 4,
0111 = 8, 0011 = 0.5, 0010 = 0.25, 0001 = 0.125
1000 = -0, 1100 = -1, 1101 = -2, 1110 = -4,
1111 = -8, 1011 = -0.5, 1010 = -0.25, 1001 = -0.125
Тебя разве мама не учила что любое число при сложении с нейтральным элементом поля Галуа (нулём) даёт само себя.
(-0)+0=-0.
proof
0000 = 0
1000 = -0
-0+0 =-0
0000+1000=1000
1000+1000=0000
1000-1000=0000
Минус на минус даёт плюс.
Минус на плюс даёт плюс.
Плюс на минус даёт плюс.
Труп на Страус даёт плюсплюс.
+0+(-0).
С++0(-х)
0 - 0 = 0 + (-0) = 0000 + 1000 = 1000
При вычитании тоже кстати (underflow)
0000 - 1000 = 1000
а+(-а) = 0
разве нет?
>а+(-а) = 0
Идём дальше.
a=0;
0+(-а) = 0
-a = 0 - 0
5 + (-5) = 0
Чтоб путаницы с нулями не было.
Банально как-то. 3 бита мантиссы и бит знака.
В смысле толку-то. Так-то можно оперировать целыми питухами, неявно помня про логарифмическую шкалу.
> Latest release: ClearPath OS 2200 Release 16.0 / February 27, 2015
> 36 bit words
> CHAR_BIT == 9
> ones complement
> 72 bit non-IEEE floating point
> separate address space for code and data
Страшный сон говнокодера.
http://www.unisys.com/offerings/high-end-servers/clearpath-forward-systems/clearpath-forward-dorado-systems
https://en.wikipedia.org/wiki/UNIVAC_1100/2200_series#UNISYS_2200_series
Оказывается, там умножители могут работать в режиме 9х9 бит и 18х18 бит. А встроенные блоки памяти умеют ширину в 9, 18 и 36 бит... К чему бы это?
perl
жыв еще курилко
Типа результаты indexOfов таки кощернее сравнивать с ~0, а не -1.
http://www.cplusplus.com/reference/string/string/find/
size_t is an unsigned integral type (the same as member type string::size_type).
Кощернее сравнивать с std::string::npos и не умничать.
static const size_t npos = -1;
size_t is an unsigned integral type
Спасибо, не надо.
Не устаю поражаться крестоблядскому упорству. Обосраться на ровном месте получить underflow и/или конвертацию signed в unsigned прямо в документации.
Тогда они еще большие мудаки чем можно себе представить. Потому что (~0 - 1) ни разу не largest possible representable value.
Впрочем крестоблядкам не привыкать подъедать неортогональную блевотину сиплюструпа.
This constant is defined with a value of -1, which because size_t is an unsigned integral type, it is the largest possible representable value for this type.
Выдающаяся Щизофрения в одном предложении штандарта.
Что значит не надо?
find и прочее явно декларируют, что возвращают npos в случае неудачи. Можешь сравнивать с чем-то другим, но тогда ССЗБ.
Эквивалент -1 там или -42 - дело, не имеющее большой практической важности.
> static const size_t npos = -1;
В либе gcc там явный каст:
static const size_type npos = static_cast<size_type>(-1);
То что беззнаковая -1 оксюморон. Она не нужна.
>В либе gcc там явный каст:
>static const size_type npos = static_cast<size_type>(-1);
Костыли-костылики. На какие только люди не идут ухищрения, чтобы не использовать побитовое отрицание или знаковые числа.
А можно используя крестобляские крестошаблоны заставить крестокомпилер выдать ошибку когда вылезешь out of bounds?
Для других случаев по аналогии
Как что-то плохое. Она определена стандартом. Число загоняется в допустимый диапазон добавлением/вычитанием соотв. степени двойки. Всего то.
unsigned в signed как раз и не определена.
> 2 If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2n where n is the number of bits used to represent the unsigned type). [ Note: In a two’s complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation) . —end note ]
> 3 If the destination type is signed, the value is unchanged if it can be represented in the destination type (and bit-field width); otherwise, the value is implementation-defined.
результат signed → unsigned чётко установлен стандартом, результат unsigned → signed установлен стандартом, если значение пожно представить в целевом типе. Иначе мы отданы на милость разработчиков компилятора.
Но из него следует, что two's complement — самое естественное представление чисел со знаком, остальные — от лукавого.
Либо послать нахуй нумерацию с нуля. Тогда вообще будет охуенно - нуль - это и указатель в никуда, и индекс в никуда.
Согласен.
Обосрались конкретно с миксом знаковости/беззнаковости.
Вот size_t допустим 16.
65534 - еще индекс. 65535 - уже not found.
Кстати, стандарт завязан на двоичные компьютеры. Для троичных/десятичных/... придётся другой язык выдумывать или эмулировать.
беззнаковые в знаковые implementation-defined, aka "делай, что быстрее"
Ерланг тоже с 1 нумерует. Оказывается, не зря.
А вдруг элемент чисто гипотетически находится на позиции 2^n-1.
According to the 1999 ISO C standard (C99), size_t is an unsigned integer type of at least 16 bit (see sections 7.17 and 7.18.3).
Что вполне реально, кстати.
не всёж под кучу отдавать, должен же еще лоадер туда user32, advapi итд загрузить
> лоадер туда user32, advapi итд
Ну т.е. даже 2 гига процессу не достанется...
>>части адресного пространства живут йадро
не тоже ли самое?
Вот про дрова не понял
Ну и еще чтобы не оказалось что мы о разном: мы говорим о виртуальном адресном пространстве программы (не ядра!), да?
Так точно. И оно в дефолтной конфигурации винды простирается от 0 до 0x7FFFFFFF (вроде можно переключить каким-то ключиком на 0..0xBFFFFFFF).
А всё что выше - ядерная область, которая во всех процессах замапана одинаково. И непривилегированному коду туда путь заказан - за попытку обратиться по виртуальному адресу 0x80000000 и выше прогу тупо убьют (ну или вбросят SEH, ок).
Или я туплю и там не так?
З.Ы. user32, advapi - самые обычные юзермодные дллки. Ты сам такие можешь написать. Даже ntdll никакой магии в себе не содержит.
присловутый ключик ядра /3gb еще со времени win2k
Я и не знал что бывают не иееешнве питухи