Безопасно ли использовать -1 для установки всех битов в истинное значение?

Я видел, как этот шаблон часто используется в C и C ++.

unsigned int flags = -1;  // all bits are true

Это хороший портативный способ сделать это? Или пользуется 0xffffffffили ~0лучше?

Я рекомендую вам делать это именно так, как вы показали, так как это наиболее простой способ. Инициализировать, -1который будет работать всегда , независимо от фактического представления знака, но ~иногда будет иметь удивительное поведение, потому что вам потребуется правильный тип операнда. Только тогда вы получите самое высокое значение unsignedтипа.

В качестве примера возможного сюрприза рассмотрим этот:

unsigned long a = ~0u;

Он не обязательно сохранит шаблон со всеми битами 1 a. Но сначала он создаст шаблон со всеми битами 1 в элементе unsigned int, а затем назначит его a. Что происходит, когда unsigned longбитов больше, так это то, что не все из них равны 1.

И рассмотрим этот вариант, который не сработает на представлении дополнения, отличном от двух:

unsigned int a = ~0; // Should have done ~0u !

Причина в том, что ~0нужно инвертировать все биты. Инвертирование, которое даст результат -1на машине с дополнением до двух (что нам и нужно!), Но не даст результата -1на другом представлении. На машине с дополнением до единицы это дает ноль. Таким образом, на машине с дополнением до единицы указанное выше будет инициализировано aнулем.

Вы должны понимать, что все дело в значениях, а не в битах. Переменная инициализируется значением . Если в инициализаторе вы измените биты переменной, используемой для инициализации, значение будет сгенерировано в соответствии с этими битами. Значение, необходимое для инициализации aмаксимально возможным значением, - это -1или UINT_MAX. Второй будет зависеть от типа a- вам нужно будет использовать ULONG_MAXдля unsigned long. Однако первый не будет зависеть от его типа, и это хороший способ получить наибольшее значение.

Мы не говорим о том -1, все ли биты равны единице (не всегда). И мы не говорим о том ~0, все ли биты едины (конечно, есть).

Но мы говорим о том, каков результат инициализированной flagsпеременной. И для этого, только-1 будет работать с каждым типом и машиной.

• unsigned int flags = -1; портативный.
• unsigned int flags = ~0; не переносится, потому что он полагается на представление с дополнением до двух.
• unsigned int flags = 0xffffffff; не переносится, потому что предполагает 32-битные целые числа.

Если вы хотите установить все биты способом, гарантированным стандартом C, используйте первый.

Честно говоря, я думаю, что все fff более читабельны. Что касается комментария о том, что это антипаттерн, если вам действительно важно, чтобы все биты были установлены / очищены, я бы сказал, что вы, вероятно, находитесь в ситуации, когда вы все равно заботитесь о размере переменной, что потребовало бы чего-то вроде повышения :: uint16_t и т. д.

Способ, позволяющий избежать упомянутых проблем, - это просто сделать:

unsigned int flags = 0;
flags = ~flags;

Портативный и в точку.

Я не уверен, что использование unsigned int для флагов является хорошей идеей в первую очередь для C ++. А как насчет битсета и тому подобного?

std::numeric_limit<unsigned int>::max()лучше, потому что 0xffffffffпредполагает, что unsigned int является 32-битным целым числом.

unsigned int flags = -1;  // all bits are true

"Это хороший [,] портативный способ сделать это?"

Портативный? Да .

Хорошо? Спорный , о чем свидетельствует вся путаница, показанная в этой ветке. Достаточная ясность, чтобы ваши товарищи-программисты могли понять код без путаницы, должна быть одним из критериев, которые мы измеряем для хорошего кода.

Кроме того, этот метод подвержен предупреждениям компилятора . Чтобы обойти предупреждение без ущерба для вашего компилятора, вам потребуется явное приведение. Например,

unsigned int flags = static_cast<unsigned int>(-1);

Явное приведение требует, чтобы вы обращали внимание на целевой тип. Если вы обращаете внимание на тип цели, то, естественно, вы избежите ошибок других подходов.

Я бы посоветовал обратить внимание на целевой тип и убедиться, что нет неявных преобразований. Например:

unsigned int flags1 = UINT_MAX;
unsigned int flags2 = ~static_cast<unsigned int>(0);
unsigned long flags3 = ULONG_MAX;
unsigned long flags4 = ~static_cast<unsigned long>(0);

Все это правильно и более очевидно для ваших коллег-программистов.

И с C ++ 11 : мы можем использовать, autoчтобы сделать любое из этих действий еще проще:

auto flags1 = UINT_MAX;
auto flags2 = ~static_cast<unsigned int>(0);
auto flags3 = ULONG_MAX;
auto flags4 = ~static_cast<unsigned long>(0);

Я считаю правильное и очевидное лучше, чем просто правильное.

Стандарт гарантирует преобразование -1 в любой беззнаковый тип как все-единицы. Использование, ~0Uкак правило, плохо, поскольку 0имеет тип unsigned intи не будет заполнять все биты большего беззнакового типа, если вы явно не напишете что-то вроде ~0ULL. В нормальных системах он ~0должен быть идентичен -1, но поскольку стандарт допускает представления с дополнением до единицы и знаком / величиной, строго говоря, он не переносится.

Конечно, всегда нормально писать, 0xffffffffесли вы знаете, что вам нужно ровно 32 бита, но -1 имеет то преимущество, что он будет работать в любом контексте, даже если вы не знаете размер типа, например макросы, которые работают с несколькими типами , или если размер типа зависит от реализации. Если вы знаете тип, другой безопасный способ , чтобы получить все-онов есть предел макросов UINT_MAX, ULONG_MAX, ULLONG_MAXи т.д.

Лично я всегда использую -1. Это всегда работает, и вам не нужно об этом думать.

Пока у вас есть #include <limits.h>один из ваших включений, вы должны просто использовать

unsigned int flags = UINT_MAX;

Если вам нужно много битов, вы можете использовать

unsigned long flags = ULONG_MAX;

Эти значения гарантированно будут иметь все биты значений результата, равные 1, независимо от того, как реализованы целые числа со знаком.

Да. Как упоминалось в других ответах, -1это самый портативный; однако он не очень семантичен и вызывает предупреждения компилятора.

Чтобы решить эти проблемы, попробуйте этот простой помощник:

static const struct All1s
{
    template<typename UnsignedType>
    inline operator UnsignedType(void) const
    {
        static_assert(std::is_unsigned<UnsignedType>::value, "This is designed only for unsigned types");
        return static_cast<UnsignedType>(-1);
    }
} ALL_BITS_TRUE;

Использование:

unsigned a = ALL_BITS_TRUE;
uint8_t  b = ALL_BITS_TRUE;
uint16_t c = ALL_BITS_TRUE;
uint32_t d = ALL_BITS_TRUE;
uint64_t e = ALL_BITS_TRUE;

Я бы не стал делать -1. Это довольно неинтуитивно (по крайней мере, для меня). Присвоение подписанных данных беззнаковой переменной кажется нарушением естественного порядка вещей.

В вашей ситуации я всегда использую 0xFFFF. (Конечно, используйте правильное количество F для переменного размера.)

[Кстати, я очень редко вижу трюк с -1 в реальном коде.]

Кроме того, если вы действительно заботитесь об отдельных битов в vairable, было бы хорошей идеей , чтобы начать работу с фиксированной шириной uint8_t, uint16_t, uint32_tтипы.

На процессорах Intel IA-32 нормально записать 0xFFFFFFFF в 64-битный регистр и получить ожидаемые результаты. Это связано с тем, что IA32e (64-битное расширение IA32) поддерживает только 32-битные немедленные. В 64-битных инструкциях 32-битные непосредственные символы расширяются до 64- битных .

Следующее является незаконным:

mov rax, 0ffffffffffffffffh

Следующее помещает 64 единицы в RAX:

mov rax, 0ffffffffh

Для полноты изложения в нижнюю часть RAX (также известного как EAX) помещается 32 единицы:

mov eax, 0ffffffffh

И на самом деле у меня случались сбои программ, когда я хотел записать 0xffffffff в 64-битную переменную, и вместо этого я получил 0xffffffffffffffff. В C это будет:

uint64_t x;
x = UINT64_C(0xffffffff)
printf("x is %"PRIx64"\n", x);

результат:

x is 0xffffffffffffffff

Я подумал опубликовать это как комментарий ко всем ответам, в которых говорилось, что 0xFFFFFFFF предполагает 32 бита, но так много людей ответили на него, я решил, что добавлю его как отдельный ответ.

См. Ответ Литба для очень четкого объяснения проблем.

Я не согласен с тем, что, строго говоря, нет никаких гарантий ни в том, ни в другом случае. Я не знаю ни одной архитектуры, которая не представляла бы беззнаковое значение `` на единицу меньше двух в степени числа битов '', когда все биты установлены, но вот что на самом деле говорит Стандарт (3.9.1 / 7 плюс примечание 44):

Представления целочисленных типов должны определять значения с использованием чистой двоичной системы счисления. [Примечание 44:] Позиционное представление для целых чисел, использующее двоичные цифры 0 и 1, в котором значения, представленные последовательными битами, являются аддитивными, начинаются с 1 и умножаются на последовательную интегральную степень 2, за исключением, возможно, бита с самая высокая позиция.

Это оставляет возможность для одного из битов быть чем-либо вообще.

Хотя 0xFFFF(или 0xFFFFFFFFи т. Д.) Может быть легче читать, это может нарушить переносимость кода, который в противном случае был бы переносимым. Рассмотрим, например, библиотечную подпрограмму для подсчета количества элементов в структуре данных, для которых установлены определенные биты (точные биты указываются вызывающей стороной). Процедура может быть полностью независимой от того, что представляют собой биты, но все же должна иметь константу «все биты установлены». В таком случае -1 будет намного лучше, чем шестнадцатеричная константа, поскольку она будет работать с любым размером бит.

Другая возможность, если typedefдля битовой маски используется значение, - это использовать ~ (bitMaskType) 0; если битовая маска имеет только 16-битный тип, в этом выражении будет установлено только 16 бит (даже если int в противном случае будет 32 бита), но поскольку все, что требуется, будет 16 бит, все должно быть в порядке при условии, что один фактически использует соответствующий тип при приведении типов.

Между прочим, у выражений формы longvar &= ~[hex_constant]есть неприятная ошибка, если шестнадцатеричная константа слишком велика, чтобы поместиться в int, но она уместится в unsigned int. Если an int- 16 бит, то longvar &= ~0x4000;или longvar &= ~0x10000; очистит один бит longvar, но longvar &= ~0x8000;очистит бит 15 и все биты выше этого. Подходящие значения intбудут иметь оператор дополнения, примененный к типу int, но результат будет расширен знаком long, установив старшие биты. Для слишком больших значений unsigned intбудет применяться оператор дополнения к типу long. Однако значения, находящиеся между этими размерами, будут применять оператор дополнения к типу unsigned int, который затем будет преобразован в тип longбез расширения знака.

Практически: да

Теоретически: Нет.

-1 = 0xFFFFFFFF (или любой другой размер int на вашей платформе) верно только с двумя арифметическими дополнениями. На практике это будет работать, но существуют устаревшие машины (мэйнфреймы IBM и т. Д.), На которых у вас есть фактический знаковый бит, а не представление с дополнением до двух. Предлагаемое вами решение ~ 0 должно работать везде.

Как уже упоминалось, -1 - это правильный способ создать целое число, которое будет преобразовано в беззнаковый тип со всеми битами, установленными в 1. Однако самая важная вещь в C ++ - это использование правильных типов. Следовательно, правильный ответ на вашу проблему (который включает ответ на заданный вами вопрос) таков:

std::bitset<32> const flags(-1);

Он всегда будет содержать точное количество битов, которые вам нужны. Он создает a std::bitsetсо всеми битами, установленными в 1 по тем же причинам, которые упоминались в других ответах.

Это, конечно, безопасно, так как -1 всегда будет иметь все доступные биты, но мне больше нравится ~ 0. -1 просто не имеет особого смысла для unsigned int. 0xFF... нехорошо, потому что это зависит от ширины шрифта.

Я говорю:

int x;
memset(&x, 0xFF, sizeof(int));

Это всегда даст желаемый результат.

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

Назначение -1 работ для любого знака целого типа (без знака Int, uint8_t, uint16_t и т.д.) для обоих C и C ++.

В качестве альтернативы для C ++ вы можете:

1. Включите <limits>и используйтеstd::numeric_limits< your_type >::max()
2. Напишите пользовательскую шаблонную функцию (это также позволило бы провести некоторую проверку работоспособности , т. Е. Если тип назначения действительно является неподписанным типом)

Целью может быть добавление большей ясности, так как при назначении -1всегда требуется пояснительный комментарий.

Способ сделать значение более очевидным и при этом избежать повторения типа:

const auto flags = static_cast<unsigned int>(-1);

да, показанное представление очень правильное, как если бы мы сделали это наоборот, вам потребуется, чтобы оператор перевернул все биты, но в этом случае логика довольно проста, если мы рассмотрим размер целых чисел в машине

например, на большинстве машин целое число составляет 2 байта = 16 бит, максимальное значение, которое оно может содержать, равно 2 ^ 16-1 = 65535 2 ^ 16 = 65536

0% 65536 = 0-1% 65536 = 65535, что соответствует 1111 ............. 1, и все биты установлены в 1 (если мы рассматриваем классы остатка по модулю 65536), следовательно, это много прямо вперед.

я думаю

нет, если вы рассматриваете это понятие, оно идеально подходит для неподписанных целых, и это действительно работает

просто проверьте следующий фрагмент программы

int main () {

unsigned int a=2;

cout<<(unsigned int)pow(double(a),double(sizeof(a)*8));

unsigned int b=-1;

cout<<"\n"<<b;

getchar();

return 0;

}

ответ для b = 4294967295, который равен -1% 2 ^ 32 для 4-байтовых целых чисел

следовательно, это совершенно верно для целых чисел без знака

в случае каких-либо неточностей сообщите пожалуйста