Пн июл 09, 2012 14:32:25
if((0b100010000000000001 &(1<<15))!=0) {
return 1;
} else {
return 0;
}
Пн июл 09, 2012 14:49:34
Пн июл 09, 2012 14:50:09
a_skr писал(а):а если явно long задать?
if((0b100010000000000001L &(1L<<15))!=0)
Пн июл 09, 2012 14:51:48
coding писал(а):a_skr писал(а):а если явно long задать?
if((0b100010000000000001L &(1L<<15))!=0)
Явно - это как?
Пн июл 09, 2012 14:55:58
Пн июл 09, 2012 15:30:14
Пн июл 09, 2012 16:13:36
Пн июл 09, 2012 16:14:15
Пн июл 09, 2012 18:38:01
Нужно быть где-то в глубине души готовым к тому, что long может быть и 64 бита. Ну вот придётся писать библиотечку обмена со своим устройством для работы из Linux/64 и по неосторожности получите что-то типа того, что FTDI подарила (лучше бы уже не трогали, раз промахнулись поначалу).a_skr писал(а):определяется типом при объявлении переменной. например long - 32 бита, char - 8 и т.д.
Привыкайте не на 8, а на CHAR_BITS -- тогда точно проблем не будет никогда.a_skr писал(а):можно sizeof использовать, умноженный на 8, но это не совсем "программно", т.к. вычисляется на этапе компиляции.
#include <limits.h> // Тут же и CHAR_BITS определён
Вт июл 10, 2012 08:14:08
я для себя даже придумать такую ситуацию не могу, где бы это понадобилось надеюсь, привыкать не придется.avreal писал(а):Привыкайте не на 8, а на CHAR_BITS -- тогда точно проблем не будет никогда.
Вт июл 10, 2012 19:05:04
Что я не так делаю?
Нужно быть где-то в глубине души готовым к тому, что long может быть и 64 бита. ... Привыкайте не на 8, а на CHAR_BITS
Ср июл 11, 2012 09:40:09
* Сам давно им пользуюсь.YS писал(а):Я бы предложил привыкать использовать stdint.h и его [u]intNN_t. Вот там разрядность точно гарантируется.
uint8_t i = 255; // займёт одну ячейку памяти в 16 бит
...
i = i + 1; // будет произведено маскирование после инкремента
...
if (i != 0) puts("Всё пропало, шеф!")
Ср июл 11, 2012 18:20:55
Строго говоря, гарантируется не разрядность а поведение.