typedef uint8_t T_BOOL;Это все еще стоит?

Question

Я пересматриваю рекомендации по кодированию для C, и у нас все еще есть руководство к typedef uint8_t для логических значений. Я работаю в компании в автомобильной промышленности, поэтому занимаюсь встраиваемым программным обеспечением и обычно работаю с микропроцессорами Renesas вместе с компиляторами GreenHills.

Я думаю, что с тех пор, как C99 существует в течение стольких лет, определение типаизбыточно, и я ожидаю, что все компиляторы для современных платформ будут поддерживать _Bool. Итак, стоит ли еще typedef?

Бонусный вопрос: Я пытаюсь составить некоторые рекомендации для C ++. У меня относительно ограниченный опыт использования C ++, но, опять же, я считаю, что typedef для bool не должно быть вообще полезным. Должны ли мы использовать основной тип C ++ bool или есть какая-то причина, по которой мы должны вместо этого использовать пользовательский typedef ed T_BOOL?

Answer 1

Это просто:

• Если вы используете стандартный C, то используйте bool из stdbool.h. _Bool тоже хорошо. Уродливые определения типов не подходят и являются плохой практикой.
• Если вы вынуждены работать со старым C90, вы должны использовать некрасивые определения типов.

---

Предполагается, что C90:

Нет абсолютно никакого вреда при использовании 8-битного типа для логического определения типа. 8-битный тип сэкономит немного оперативной памяти. Это можно сделать так:

typedef uint8_t BOOL;
#define FALSE 0u
#define TRUE  1u

Наиболее распространенная форма - это, вероятно, typedef enum { FALSE, TRUE } BOOL;.

Никогда не используйте все строчные буквы! Поскольку bool, false и true будут конфликтовать со стандартом, если вы портируете на стандартный компилятор C.

Все эти домашние формы - плохая практика и устаревший способ написания C. Не остается никаких оправданий для того, чтобы придерживаться опасного C90, особенно в автомобильных системах, которые, как правило, критичны к безопасности.

Что касается MISRA-C: 2012, то в нем просто говорится, что у вас должен быть какой-то логический тип,Он поддерживает обратную совместимость с C90 и, следовательно, не обеспечивает bool. Однако в нем много правил обработки логических типов, и он запрещает использовать их вместе с различными арифметическими формами.

---

Для совместимости с C ++ вам обязательно следует использовать стандарт C bool. Этот тип был явно разработан с учетом совместимости с C ++.

Answer 2

В тот момент, когда вы (ab) используете правила продвижения C для сохранения логического значения во всем, кроме типа выражения, предоставляемого операторами сравнения, то есть int, вы находитесь в состоянии греха. На более серьезном замечании: я не могу представить случай, когда тип, в котором я храню булеву часть информации, имел бы значение, за исключением огромного количества логических значений и написания довольно многих критически важных частейАвтомобильного программного обеспечения, я едва ли могу представить себе случай, когда такая структура данных могла бы быть полезной. Почти каждая информация, которую я когда-либо обрабатывал, которая содержала решение «да / нет», также несла связку связанных данных, и поэтому естественная схема хранения была структурой. Я никогда не уклонялся от битовых полей, независимо от того, что об этом говорит нынешний стандарт MISRA (дело против них рассыпается в прах, если вы продумаете контраргументы с надетой шляпой «Sane Safety Software Expert»). Когда это было не так, это был какой-то глобальный флаг, и поэтому размер формата хранения не имел значения. Итак, вопрос в том, какие оставшиеся приложения будут иметь значение для логического формата хранения? Единственное, о чем я могу думать, это размер стека или, скорее, потеря возможности делать вызов с параметрами только в регистрах, если вы не выбрали наименьший доступный размер. Это сразу вызывает два контраргумента: функции со многими слабосвязанными логическими параметрами крайне подозрительны, и даже если они существуют, от них не должны зависеть ни производительность, ни потребление памяти (если они являются узкими местами, это тоже крайне подозрительно). Может быть небольшой выигрыш в максимальном размере стека, если у вас есть иерархия вызовов с логическим значением здесь и там, но это IME, а не место для микрооптимизации.

Чтобы дать ответ TL; DR: формат не должен отклоняться от того, что ожидают (новые) программисты в вашей команде, и это, скорее всего, тот, который широко использовался / стандарт в течение последнего десятилетия. Если хранимый тип ваших логических значений действительно имеет значение, я, совершенно не спрашивая, осмелюсь удаленно диагностировать проблему построения программного обеспечения.

Answer 3

Для нового кода на самом деле нет оснований переопределять стандартные типы - в нашей компании мы предполагаем использование bool, true и false, поскольку это мешает разным командам и разработчикам разрабатыватьих собственные (иногда слегка несовместимые) варианты этих типов.

Для более старого кода, который имеет дело с ранее объявленным bool / true / false, возможно из устаревших сред, иногда полезно использовать псевдоним (через typedef,или #define) существующие типы в _Bool. Это обычно проблема для рамок, а не для конкретных программ. Примеры включают в себя X11 (Boolean), Xt (_XtBoolean), ...

Я считаю, что причина включения обоих _Bool и bool состояла в том, чтобы позволить существующему коду, который уже создал 'bool', продолжить работу без необходимости делатькод изменяется в результате введения «стандартного» bool, false и true.