Я учусь на первом курсе информатики, и мой профессор сказал, что #define запрещен отраслевыми стандартами вместе с #if, #ifdef, #else и некоторыми другими директивами препроцессора. Он использовал слово «забанен» из-за неожиданного поведения.
Это точно? Если да, то почему?
Существуют ли на самом деле какие-либо стандарты, запрещающие использование этих директив?
Впервые я об этом услышал.
Нет; #define и так далее. Иногда используется слишком широко, но определенно используется. Есть места, где стандарт C требует использования макросов - этого легко избежать. Например, в §7.5 Ошибки <errno.h> говорится:
Макросы
EDOM EILSEQ ERANGEкоторые расширяются до целочисленных константных выражений с типом
int, отличными положительными значениями и которые подходят для использования в директивах предварительной обработки#if; …
Учитывая это, ясно, что не все отраслевые стандарты запрещают использование макросов препроцессора C. Однако существуют стандарты «передовой практики» или «руководящие принципы кодирования» от различных организаций, которые предписывают ограничения на использование препроцессора C, хотя ни один из них не запрещает его использование полностью - это врожденная часть C, и ее нельзя полностью избежать. Часто эти стандарты предназначены для людей, работающих в критических для безопасности областях.
Один из стандартов, который вы можете проверить - это стандарт MISRA C (2012); это имеет тенденцию запрещать вещи, но даже это признает, что #define и др. иногда необходимы (раздел 8.20, правила с 20.1 по 20.14 относятся к препроцессору C).
Стандарты кодирования C НАСА GSFC (Центр космических полетов Годдарда) просто говорят:
Макросы следует использовать только при необходимости. Чрезмерное использование макросов может затруднить чтение и поддержку кода, поскольку код больше не читает и не ведет себя как стандартный C.
Обсуждение после этого вступительного заявления иллюстрирует допустимое использование макросов функций.
В CERT Coding Standard есть ряд рекомендаций по использованию препроцессора и подразумевает, что вы должны минимизировать использование препроцессора, но не запрещает его использование.
Страуструп хотел бы, чтобы препроцессор не использовался в C ++, но этого еще не произошло. Как Питер примечания, некоторые стандарты C ++, такие как Стандарты кодирования JSF AV C ++ (Joint Strike Fighter, Air Vehicle) примерно с 2005 г. предписывают минимальное использование препроцессора C. По сути, правила JSF AV C ++ ограничивают его #include и танец #ifndef XYZ_H / #define XYZ_H /… / #endif, который предотвращает многократное включение одного заголовка. В C ++ есть некоторые параметры, которые недоступны в C - в частности, лучшая поддержка типизированных констант, которые затем можно использовать в тех местах, где C не позволяет их использовать. См. Также static const vs #define vs enum, где обсуждаются проблемы.
Рекомендуется свести к минимуму использование препроцессора - им часто злоупотребляют, по крайней мере, настолько, насколько он используется (см. Boost препроцессор 'библиотека' для иллюстраций того, как далеко вы можете зайти с препроцессором C).
Препроцессор является неотъемлемой частью C и #define, #if и т. Д. Нельзя полностью избежать. Утверждение профессора в вопросе в целом неверно: #define запрещен отраслевыми стандартами вместе с #if, #ifdef, #else и некоторыми другими макросами в лучшем случае является преувеличением, но может быть поддерживаемым с явной ссылкой на определенные отраслевые стандарты (но рассматриваемые стандарты не включают ISO / IEC 9899: 2011 - стандарт C).
Обратите внимание, что Дэвид Хаммен имеет предоставила информацию об одном конкретном стандарте кодирования C - Стандарт кодирования C JPL - который запрещает многие вещи, которые многие люди используют в C, включая ограничение использования препроцессора C (и ограничение использования распределения динамической памяти и запрет рекурсии - прочтите его, чтобы узнать, почему, и решить, являются ли эти причины имеют отношение к вам).
#define MAX(a,b) ((a>b)?(a):(b)) в порядке, несмотря на потенциальную опасность.
- person Sneftel; 28.12.2015
errno приводит к UB.
- person Andrew Henle; 28.12.2015
#define не должна использоваться для создания встроенных макросов. Вместо этого должны использоваться встроенные функции. Правило AV 30 гласит, что директива препроцессора #define не должна использоваться для определения постоянных значений. Вместо этого к объявлениям переменных следует применять квалификатор const для определения значений констант. Правило AV 31 гласит, что директива препроцессора #define будет использоваться только как часть техники для предотвращения множественных включений одного и того же файла заголовка.
- person Peter; 29.12.2015
offsetof() и подобных макросов).
- person Peter; 29.12.2015
offsetof() изредка, но очень редко, оправдано.
- person Jonathan Leffler; 29.12.2015
Нет, использование макросов не запрещено.
Фактически, использование #include предохранителей в файлах заголовков - это один из распространенных методов, который часто является обязательным и поощряется принятыми руководящими принципами кодирования. Некоторые утверждают, что #pragma once является альтернативой этому, но проблема в том, что #pragma once - по определению, поскольку прагмы - это ловушка, предоставляемая стандартом для расширений, специфичных для компилятора, - нестандартна, даже если она поддерживается рядом компиляторы.
Тем не менее, существует ряд отраслевых рекомендаций и рекомендуемых практик, которые активно препятствуют использованию любых макросов, кроме #include охранников, из-за проблем, которые вызывают макросы (несоблюдение объема и т. Д.). При разработке на C ++ использование макросов осуждается даже сильнее, чем при разработке на C.
Отговаривать от использования чего-либо - это не то же самое, что запрещать это, поскольку все еще можно законно использовать это, например, путем документального обоснования.
Некоторые стандарты кодирования могут препятствовать или даже запрещать использование #define для создания функционально-подобных макросов, которые принимают аргументы, например
#define SQR(x) ((x)*(x))
потому что а) такие макросы небезопасны по типу, и б) кто-то неизбежно напишет SQR(x++), что является плохим juju.
Некоторые стандарты могут препятствовать или запрещать использование #ifdefs для условной компиляции. Например, следующий код использует условную компиляцию для правильной печати значения size_t. Для C99 и более поздних версий вы используете спецификатор преобразования %zu; для C89 и более ранних версий вы используете %lu и приводите значение к unsigned long:
#if __STDC_VERSION__ >= 199901L
# define SIZE_T_CAST
# define SIZE_T_FMT "%zu"
#else
# define SIZE_T_CAST (unsigned long)
# define SIZE_T_FMT "%lu"
#endif
...
printf( "sizeof foo = " SIZE_T_FMT "\n", SIZE_T_CAST sizeof foo );
Некоторые стандарты могут предписывать, чтобы вместо этого вы реализовали модуль дважды, один раз для C89 и ранее, один раз для C99 и более поздних версий:
/* C89 version */
printf( "sizeof foo = %lu\n", (unsigned long) sizeof foo );
/* C99 version */
printf( "sizeof foo = %zu\n", sizeof foo );
а затем позвольте Make (или Ant или любой другой инструмент сборки, который вы используете) для компиляции и связывания правильной версии. Для этого примера это было бы нелепым излишеством, но я видел код, который представлял собой неотслеживаемое «крысиное гнездо» из #ifdef, в котором следовало выделить этот условный код в отдельные файлы.
Однако мне неизвестна какая-либо компания или отраслевая группа, которая полностью запретила использование инструкций препроцессора.
Макросы нельзя «забанить». Утверждение - ерунда. В прямом смысле.
Например, раздел 7.5 Ошибки <errno.h> стандарта C Standard требует использования макросов:
1 Заголовок
<errno.h>определяет несколько макросов, связанных с сообщением об ошибках.2 Макросы
EDOM EILSEQ ERANGEкоторые расширяются до целочисленных константных выражений с типом
int, отличными положительными значениями и которые подходят для использования в директивах предварительной обработки#if; иerrnoкоторый расширяется до изменяемого lvalue, имеющего тип
intи длительность локального хранилища потока, значение которой устанавливается на положительный номер ошибки несколькими библиотечными функциями. Если определение макроса подавлено для доступа к реальному объекту или программа определяет идентификатор с именемerrno, поведение не определено.
Таким образом, макросы не только являются обязательной частью C, в некоторых случаях их неиспользование приводит к неопределенному поведению.
errno без использования макроса без вызова UB? В стандарте четко указано, что errno - это макрос, и четко указано, что подавление макроса errno или другое определение вашего собственного errno приводит к UB. И как вообще можно писать надежный код без использования errno? Некоторые системные вызовы все же можно прервать и вернуть ошибку с errno установлен в EINTR, даже если для всех ваших сигнальных флагов установлено SA_RESTART. Следовательно, если вы используете errno, вы не сможете писать код без макросов, если не вызовете UB.
- person Andrew Henle; 28.12.2015
errno без использования макроса required, вы вызовете UB. Прозрачный?
- person Andrew Henle; 29.12.2015
errno без использования макросов, вы вызываете UB: Если определение макроса подавляется для доступа к реальному объекту ... поведение не определено. Это не имеет ничего общего с использованием макросы неправильно - если вы не используете макросы, но каким-то образом используете errno, вы вызвали UB.
- person Andrew Henle; 29.12.2015
errno или макросов, определенных в стандарте, и не защищают от множественного включения с помощью защиты включения. Это было бы нелепо. Что они действительно запрещают, так это использование #if и #define в любом контексте, кроме контекста включения.
- person David Hammen; 29.12.2015
errno или макросов, определенных в стандарте, и не защищают от множественного включения с помощью защиты включения. Это было бы нелепо. Что они действительно запрещают, так это использование #if и #define в любом контексте, кроме контекста включения. Итак, вы работали там, где они запрещают макросы, кроме случаев, когда они этого не делают . Классная история.
- person Andrew Henle; 30.12.2015
#if и #define в пользовательском коде, а не об использовании директив препроцессора в системных заголовках. Обсуждение errno неуместно.
- person David Hammen; 30.12.2015
#define запрещен отраслевыми стандартами вместе с #if, #ifdef, #else и некоторыми другими директивами препроцессора ... НЕТ упоминания кода пользователя. errno является доказательством того, что утверждение - ерунда, потому что Стандарт C требует, чтобы errno был макросом - #define! - и поэтому следующие макросы не могут быть забанены. Тот факт, что ваши исключения изложены очень тщательно, является фактическим признанием с вашей стороны того, что они не запрещены. Это все равно, что сказать, что ограничение скорости запрещает вождение.
- person Andrew Henle; 30.12.2015
Нет, #define не забанен. Однако неправильное использование #define может быть осуждено.
Например, вы можете использовать
#define DEBUG
в вашем коде, чтобы позже вы могли назначать части вашего кода для условной компиляции, используя #ifdef DEBUG, только для целей отладки. Не думаю, что кто-то в здравом уме захочет запретить что-то подобное. Макросы, определенные с помощью #define, также широко используются в переносимых программах для включения / выключения компиляции кода для конкретной платформы.
Однако, если вы используете что-то вроде
#define PI 3.141592653589793
ваш учитель может справедливо указать, что гораздо лучше объявить PI как константу с соответствующим типом, например,
const double PI = 3.141592653589793;
поскольку это позволяет компилятору выполнять проверку типов при использовании PI.
Точно так же (как упоминалось выше Джоном Боде) использование макросов, подобных функциям, может не одобряться, особенно в C ++, где можно использовать шаблоны. Так что вместо
#define SQ(X) ((X)*(X))
рассмотреть возможность использования
double SQ(double X) { return X * X; }
или, в C ++, еще лучше,
template <typename T>T SQ(T X) { return X * X; }
И снова идея состоит в том, что, используя возможности языка вместо препроцессора, вы позволяете компилятору выполнять проверку типа, а также (возможно) генерировать лучший код.
Когда у вас будет достаточно опыта программирования, вы будете точно знать, когда уместно использовать #define. А пока я думаю, что для вашего учителя будет хорошей идеей навязывать определенные правила и стандарты кодирования, но желательно, чтобы они сами знали и могли объяснить причины. Полный запрет на #define бессмысленен.
Это совершенно неверно, макросы широко используются в C. Новички часто используют их плохо, но это не повод запрещать их использование в промышленности. Классическое неправильное употребление - #define succesor(n) n + 1. Если вы ожидаете, что 2 * successor(9) даст 20, то вы ошибаетесь, потому что это выражение будет переведено как 2 * 9 + 1, т.е. 19, а не 20. Используйте круглые скобки, чтобы получить ожидаемый результат.
#define successor(n) ((n) + 1)
- person mirabilos; 29.12.2015
Нет. Это не запрещено. И, честно говоря, без него невозможно обойтись нетривиальным мультиплатформенным кодом.
Нет, ваш профессор ошибается, или вы что-то не расслышали.
#define - это макрос препроцессора, и макросы препроцессора необходимы для условной компиляции и некоторых соглашений, которые просто не построены на языке C. Например, в недавнем стандарте C, а именно C99, была добавлена поддержка логических значений. Но это поддерживается не языком "родным", а препроцессором #defines. См. эту ссылку на stdbool.h
*NULL или char foo[2]; foo[2];, всеми ошибками программирования. Чтобы лучше узнать, что такое неопределенное поведение, часто сокращаемое до UB, я рекомендую следующее: c2.com/cgi/wiki ? UndefinedBehavior
- person Superlokkus; 28.12.2015
errno - в стандарте конкретно указано, что неиспользование макроса errno приводит к неопределенному поведению.,
- person Andrew Henle; 28.12.2015
Макросы довольно часто используются в GNU land C, и без условных команд препроцессора нет способа правильно обрабатывать множественные включения одних и тех же исходных файлов, поэтому они кажутся мне важными языковыми функциями.
Возможно, ваш класс на самом деле написан на C ++, который, несмотря на то, что многие люди этого не делают, следует отличать от C, поскольку это другой язык, и я не могу говорить о макросах там. Или, может быть, профессор имел в виду, что запрещает их в своем классе. В любом случае я уверен, что сообществу SO было бы интересно услышать, о каком стандарте он говорит, поскольку я почти уверен, что все стандарты C поддерживают использование макросов.
#ifndef HEADER_H #define HEADER_H ... #endif)
- person R_Kapp; 28.12.2015
#pragma once? Определенно найдите его - он еще не вошел в стандарт, но он поддерживается всеми поставщиками (GCC, Clang, EDG, MSVC, Intel, Green Hills, ARM, ...) и значительно снижает вероятность совершения глупых опечаток, таких как #ifndef FOO_H #define FOOH или #ifdef FOO_H #define FOO_H или использование одного и того же макроса в двух разных файлах .h. (Это также сокращает время компиляции и устраняет священные войны из-за интервалов и отступов в #ifndef-style include guard.) У условной компиляции, конечно, есть свои применения, но #pragma once бедняги не одно из них.
- person Quuxplusone; 29.12.2015
#pragma once может никогда не попасть в ISO C ++, потому что modules, вероятно, сделает файлы .h в значительной степени неактуальными в долгосрочной перспективе, но это не повлияет на комитет ISO C, насколько я могу знать. Они могли бы стандартизировать это завтра, если бы кто-нибудь написал предложение.
- person Quuxplusone; 29.12.2015
#pragma. Поэтому предполагать, что любая прагма когда-либо будет стандартизирована, - просто фантазия - это понятие полностью расходится с тем, что такое прагмы. Тот факт, что некоторые поставщики неверно представляют некоторые из своих специфичных для них функций как стандартные, не означает, что это так.
- person Peter; 29.12.2015
Вопреки всем ответам на сегодняшний день, использование директив препроцессора часто запрещается в высоконадежных вычислениях. Из этого правила есть два исключения, использование которых разрешено в таких организациях. Это директива #include и использование защиты включения в файле заголовка. Подобные запреты более вероятны в C ++, чем в C.
Вот только один пример: 16.1.1 Используйте препроцессор только для реализации защиты включения и включения файлов заголовков с защитой включения.
Другой пример, на этот раз для C, а не C ++: Стандарт институционального кодирования JPL для C Язык программирования. Этот стандарт кодирования C не заходит так далеко до полного запрета на использование препроцессора, но приближается к нему. В частности, в нем говорится
Правило 20 (использование препроцессора) Использование препроцессора C должно ограничиваться включением файлов и простыми макросами. [Сила десяти, правило 8].
Я не одобряю и не осуждаю эти стандарты. Но говорить, что их не существует, смешно.
Если вы хотите, чтобы ваш код C взаимодействовал с кодом C ++, вы захотите объявить свои видимые извне символы, такие как объявления функций, в пространстве имен extern "C". Часто это делается с помощью условной компиляции:
#ifdef __cplusplus
extern "C" {
#endif
/* C header file body */
#ifdef __cplusplus
}
#endif
#include "c++/header.h" в коде C ++, где файл "c++/header.h" содержит: extern "C" { / #include "c/header.h" / } (с одиночными косыми чертами, указывающими новые строки - и выбор имен подкаталогов, конечно, в значительной степени произвольный), что позволило бы избежать условной компиляции при стоимость дополнительного файла. Согласен, вы показываете то, что используется чаще всего (я сам этим пользуюсь). Но на самом деле в этом нет необходимости, если вы все настроили правильно.
- person Jonathan Leffler; 01.01.2016
#if. Два файла заголовков, один из которых включает другой, просто создают вопросы.
- person jxh; 01.01.2016
Посмотрите на любой заголовочный файл, и вы увидите что-то вроде этого:
#ifndef _FILE_NAME_H
#define _FILE_NAME_H
//Exported functions, strucs, define, ect. go here
#endif /*_FILE_NAME_H */
Эти определения не только разрешены, но и критичны по своей природе, поскольку каждый раз, когда файл заголовка упоминается в файлах, он будет включаться отдельно. Это означает, что без определения вы переопределяете все, что находится между защитой, несколько раз, что в лучшем случае не может быть скомпилировано, а в худшем случае вы позже будете чесать голову, почему ваш код не работает так, как вы этого хотите.
Компилятор также будет использовать определение, как показано, здесь с gcc, что позволяет вы проверяете такие вещи, как версия компилятора, что очень полезно. В настоящее время я работаю над проектом, который необходимо скомпилировать с помощью avr-gcc, но у нас есть тестовая среда, в которой мы также запускаем наш код. Чтобы определенные файлы и регистры avr не препятствовали запуску нашего тестового кода, мы делаем что-то вроде этого:
#ifdef __AVR__
//avr specific code here
#endif
Используя это в производственном коде, дополнительный тестовый код может компилироваться без использования avr-gcc, а приведенный выше код компилируется только с использованием avr-gcc.
Если бы вы только что упомянули #define, я бы подумал, что, возможно, он имел в виду его использование для перечислений, которые лучше использовать enum, чтобы избежать глупых ошибок, таких как присвоение одного и того же числового значения дважды.
Обратите внимание, что даже в этой ситуации иногда лучше использовать #defines, чем перечисления, например, если вы полагаетесь на числовые значения, которыми обмениваются с другими системами, и фактические значения должны оставаться такими же, даже если вы добавляете / удаляете константы (для совместимости).
Однако добавить, что #if, #ifdef и т. Д. Не следует использовать, просто странно. Конечно, злоупотреблять ими, наверное, не стоит, но в реальной жизни есть десятки причин их использовать.
Он мог иметь в виду, что (при необходимости) вам не следует жестко кодировать поведение в источнике (что потребует повторной компиляции для получения другого поведения), а вместо этого использовать некоторую форму конфигурации времени выполнения.
Это единственная интерпретация, которая имела бы смысл.
#defineи так далее. Иногда используется слишком широко, но определенно используется. Есть места, где стандарт C требует использования макросов - этого легко избежать. Вы можете проверить стандарты MISRA C; они склонны запрещать вещи, но я почти уверен, что даже они признают, что#defineи др. иногда необходимы. - person Jonathan Leffler schedule 28.12.2015