есть некая переменная _Bool х;
можна ли, и если можно то как, ее инвертировать ?
тоесть 1-0-1-0-1-...........

х = !х
?

на выбор:
x = !x;
x ^= 1;
x = ~x;

X=1-X;

Что-то вспомнилась старая шутка (не C, но скорее C#), которая в данном случае выглядела бы так:

а почему при инициализации переменной компилятор проглатывает _Bool х=95;
но при последующем выводе на экран там 1 ?

Потому что _Bool это, наверное, char какой-нибудь на самом деле или другой целый тип.

Потому, что всё, отличное от нуля - это true.

Дело не в том, в каком виде хранится.
Можете даже переопределить:
BOOL_TYPE_SIZE
A C expression for the size in bits of the C++ type bool and C99 type _Bool on the target machine. If you don't define this, and you probably shouldn't, the default is CHAR_TYPE_SIZE.

Просто в C при преобразовании типа в логический, ложь(false) есть 0 (ноль). А все, что не ноль - истина (1). То есть, компилятор просто преобразовал константу типа int в логическую.

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

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

В том то и дело, что в C99 есть - _Bool

При выключенной поддержке C99 выражение

выдаст 95, а не 1

педантичный вы наш, цитируйте корректно:неужели не понятно, что изначально в Си даже не предполагалось такого типа, а _Bool в С99 - это либо костыль (подчеркивание в начале как бы намекает), либо дань моде (С++)...

ну и подчеркиваю: это моё личное мнение. я не претендую на славу Кернигана и Ричи, и даже Страуструпа

Подчеркивание и заглавная B в _Bool как раз наоборот, сделаны из-за костылей bool (GCC) и _bool (VC) уже имеющихся к тому времени на уровне системных заголовочных файлов.
И покажите мне сейчас, через 16 лет после введения стандарта C99, компилятор, его не поддерживающий.
Так что есть в действующем стандарте C логические типы данных.

А что Вы подразумеваете под

мне не ведомо. Может речь вообще про ENIAC-овские типы данных

Я же "родным" называю или описанное в действующем стандарте, либо реализуемое непосредственно компилятором. В зависимости от контекста.

Добавлено after 7 minutes 13 seconds:
Добавлю. С точки зрения большинства МК, использование логического типа данных часто не оправдано. Обычно, объем программной памяти МК намного больше, чем объем оперативной. Поэтому, нередко, имеет смысл размещать логические переменные в битах, экономя оперативную память за счет дополнительного расхода программной и незначительно меньшего быстродействия.
Это существенно, когда таких логических переменных десятки, да еще большинство из них глобальные.

если я выразился недостаточно понятно, то даю более четкий ответ: родными типами я считаю те, которые были в момент рождения языка. как известно, язык Си первоначально не содержал никаких типов, кроме численных, некоторые разновидности которых получили различные наименования. int - собственно, это все. ну и производные от него, получаемые при помощи префиксов short, long и т.п.

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

стандарты с течением времени обрастают различными вещами, все больше и больше нагружающими голову. есть с моей точки зрения полезные нововведения, есть бесполезные, а есть и вредные. и я лично для себя, чтобы поберечь свою голову, избрал путь разумного самоограничения на уровне минимально необходимого. это случилось относительно давно, примерно лет 7-8 назад, и по сей день я остаюсь в уверенности, что мой подход никогда не навредит любому начинающему программисту или программисту-любителю, который пожизненно начинающий. профессионалов прошу не беспокоиться.

итак, в чем мой принцип? вот основные его тезисы:
1. не умножай сущности без необходимости (см. _Bool)
2. упрощай записи, даже если это противоречит п.1 (не пиши в одной строке описание переменной сложного типа, вместо чего опиши один или несколько простых типов, и определи переменную в "два слова")
3. не пользуйся всеми возможностями синтаксиса, которые разрешены стандартом, ограничь себя наиболее нативно понятным набором ([]arr и arr[] - это по сути синонимы, но я никогда не пользуюсь первым вариантом)
4. не стремись к экономии строк (встречал пример, когда функция поиска подстроки в строке была реализована в виде оператора for с пустым телом, т.е. все внутри круглых скобок)

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

из новшеств С99 (в варианте GNU C99) я использую типы с явным указанием размерности - intX_t (кстати, заодно я перенял окончание _t для вводимых пользователем типов). я пользуюсь Си только для МК, и явное указание размерности типов мне представляется безусловно полезным нововведением. проблемы, правда, возникают с параноидальным режимом компиляции, когда выводятся варнинги на несоответствие типов char и uint8_t, например... что ж, за все приходится платить...

так же безусловно полезным мне представляется возможность определения переменных по месту кода, т.е. локальными для блоков кода.
возможность использования записи "интервалов значений" для оператора switch - это тоже безусловное удобство (увы, я вышел из паскаля и подспудно тяготею к его подходам).
иногда радуюсь возможности описания массивов вычисляемой размерности: хоть и не часто, но это сильно помогает.
и еще я очень благодарен изобретателям анонимных структур и юнионов - очень удобно работать со сложными типами, требующими разного способа доступа к физическим данным.
вроде бы и все...

новшество вроде bool или _Bool не считаю чем-то реально полезным и не применяю.
вопросы совместимости меня не беспокоят.

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

Я ради эксперимента сейчас в своем проекте часиков поправил 4 флага типа uint8_t на _Bool - размер прошивки остался точно таким же.
Раз нет выигрыша, то и сущности плодить не надо. imho.

Не удивительно. Я же писал выше:


Раз Вы не переопределили BOOL_TYPE_SIZE, он и остался равным 8 (CHAR_TYPE_SIZE).


_Bool позволяет выделять под логическую переменную любое количество битов, хоть 1, хоть 8, хоть 64. IMHO, для МК польза от этого очевидна.

2 ARV: и не надо было писать такие опусы. Проблема была только в том, что из Вашей фразы:


Я лично понял, что вы утверждаете, что:

и


Что для стандарта C99 и позднее является ложными утверждениями.
А значит

Вы могли внедрить в голову неверную информацию.

в какой области памяти расположены фьюз биты ?

а вам зачем?

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

да любопытство взыграло
регистры вижу, бутлоудер вижу .... а фьюзов не вижу

все как у класика

-видиш фьюзы ?
-нет
-и я не вижу, а ОНИ есть

Ну хорошо, добавил в начало


4 замены uint8_t на _Bool на размер прошивки не повлияли.
Как сделать _Bool однобитным?