- 1
value += (0<<17); // PARK bit
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+124
value += (0<<17); // PARK bit
rhaport 04.02.2015 02:27 # 0
kegdan 04.02.2015 02:35 # 0
охлол
сколько 0 не смещай - 0 будет
wvxvw 04.02.2015 09:07 # 0
bormand 04.02.2015 09:29 # 0
Хуже. В таком случае это UB.
C++98, 5.8/1
The behavior is undefined if the right operand is negative, or greater than or equal to the length in bits of the promoted left operand.
Так что да, компилятор имеет полное право единичек в ответ нахуярить или диск форматнуть :)
kegdan 04.02.2015 11:16 # 0
но это плюсы. а что говорить сишка чистая тм?
bormand 04.02.2015 11:41 # 0
Скорее всего тоже UB.
absolut 05.02.2015 18:51 # 0
"If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined."
1. UB вынесено в конец предложения
2. 'width' вместо 'length in bits' // си компактнее!
kegdan 05.02.2015 18:57 # 0
absolut 05.02.2015 19:07 # 0
я конкретно про 'width' vs 'length in bits'
И в сях интереснее читать, развязка в конце предложения. А не так сходу "убийца - дворецкий".
kegdan 05.02.2015 19:35 # 0
bormand 04.02.2015 06:44 # 0
Ну. Во-первых смешивать логику и арифметику опасно. Вдруг в value уже стоял 17й бит? Надо так: Во-вторых 17 стоит дать какое-нибудь имя, или хотя бы коммент написать...
kegdan 04.02.2015 11:06 # 0
http://ideone.com/HI2kOV
0 сколько не смещай будет 0 же. и никаких УБ
bormand 04.02.2015 11:37 # +1
А вообще, типичное поведение при сдвиге за границу примерно такое:
- если сдвиг делает сам компилятор, то в ответе будет 0 (1 << 33 == 0)
- если сдвиг делает проц - то количество сдвигаемых бит обрежется под битность числа (1 << 33 == 1 << 1 == 2)
Сам понимаешь, что если даже на таком примере всё прёт, то полагаться на это нельзя...
kegdan 04.02.2015 11:41 # 0
>Сам понимаешь, что если даже на таком примере всё прёт, то полагаться на это нельзя...
вот это меня и удивляет - такая простая и понятная операция - и нельзя на нее положиться
bormand 04.02.2015 11:44 # 0
0 << X == 0 только при 0 < X < N, где N - количество бит в сдвигаемом типе. Это гарантированно. При X >= N никаких гарантий нет. В том числе не гарантируется то, что ты вообще получишь какой-то результат. Вдруг какая-то платформа вызывает прерывание при слишком большом сдвиге? А она имеет на это полное право...
kegdan 04.02.2015 11:48 # 0
в матане такие вещи делаются, для того, что бы все срасталось. Программирование же - сугубо прикладная наука. уж лучше какое нибудь дурацкое поведение (X >= N 0 << X == 42) чем неопределенное
bormand 04.02.2015 11:57 # +1
Хочешь гарантированных поведений - пиши на жабе или шарпе. Там всё с точностью до бита расписано.
bormand 04.02.2015 12:01 # 0
А скрывать все платформозависимые фишки и сводить всё к единому поведению с точностью до бита как в жабе слишком дорого для такого байтоёбского языка, как си.
kegdan 04.02.2015 12:18 # 0
kegdan 04.02.2015 12:06 # 0
wvxvw 04.02.2015 12:11 # 0
kegdan 04.02.2015 12:20 # 0
ке?
wvxvw 05.02.2015 00:38 # 0
kegdan 05.02.2015 00:41 # 0
wvxvw 05.02.2015 10:07 # 0
kegdan 05.02.2015 11:40 # 0
wvxvw 05.02.2015 17:34 # 0
kegdan 05.02.2015 18:27 # 0
DBdev 04.02.2015 11:26 # 0
// PARK bit
написали ж :) а толку...
rhaport 04.02.2015 13:21 # 0
value &= ~(1 << 17);
а так да, смешивать логику и арифметику не стоит.
kegdan 04.02.2015 15:20 # +1
value ^= 1 << 17;
почему то искажение мне кажется более естественным чем зануление
rhaport 05.02.2015 00:20 # 0
kegdan 05.02.2015 00:23 # 0
bormand 05.02.2015 06:23 # 0
Обычно как раз в установке в 0 или в 1. Кстати, на тех же avr даже специализированная операция есть для выкалывания бит, делающая a &= ~b.
kegdan 05.02.2015 11:42 # 0
kipar 05.02.2015 11:33 # 0
Ну т.е. говнокод конечно, магические числа и нужно следить чтоб правильно все сдвинуть, но если мы не туда сдвинули то уже никакой &= не спасет.