Добрый день!
Столкнулся со следующей проблемой.
нашол код как сделать восемь таймеров написанный Alechin Jan.
Первое что кидается в глаза та это синтаксис мне непонятный.
Вот к примеру прототип функции остановки тай мера:

ну и сама функция:

Непонятно что такое IDX? Ну IN понятно, направление, очень удобно.
IDX по ходу здесь беззнаковый чар.
Ну и соответственно вопрос:
Этот синтаксис возможен через какоето макроопределение?
Может кто знает, подскажите, уверен это интерессно не только мне.
Вот ещё пример

Спасибо.

Да, typedef, или через структуру.

Стиль жуткий, не надо так делать.


Это как?

да, и через макроопределение:



и через typedef



Но думаю что конкретно в вашем примере IDX задумывался быть перечислимым типом, объявленным через enum

Ага, спасибо. Чёта мучают сомнения нащёт квалификатора перечисления
Но тогда непонятно это (Его же стиль)

Да, тогда ещё вопрос :
Если возможности препроцессора ограничены, то лучше использовать typedef используя возможности компилятора? И в каких случаях предпочтительнее #define?
Если кому не тяжело , приведите конкретный пример чтобы компилятор проглотил!
Спасибо!


ПОКАЖИ


Возможно, но мне просто интерессно. Просто в голове не укладывается как ?!

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

Просветите, плз, откуда такая категоричная постановка?

Почему-то приходится применять гораздо шире. Где не вижу тонкой грани?

Так как кусок кода мой - скажу как это описано у меня (то бишь в оригинале):


// Тип переменной, занимающей 1 байт (0..255).
typedef unsigned char BYTE;
#define MAX_BYTE ((BYTE)-1)

// Тип переменной-указателя на переменную, занимающую байт.
typedef BYTE * pBYTE;

//--------------------------------------------------------------------------------------------
// Тип индексной переменной (0..255);
typedef unsigned char IDX;
#define BAD_IDX ((IDX)-1)

//--------------------------------------------------------------------------------------------
// Тип переменной, занимающей 2 байта (0..65536).
typedef unsigned short WORD;
#define MAX_WORD ((WORD)-1)

// Макрокоманда получения значения младшего байта слова.
#define LO_BYTE(word) (BYTE)(word)

// Макрокоманда получения значения старшего байта слова.
#define HI_BYTE(word) (BYTE)((WORD)(word) >> 8)

// Макрокоманда формирования значения типа WORD из двух значений типа BYTE.
#define MAKE_WORD(lo, hi) (WORD)(((BYTE)(lo)) | ((WORD)(hi) << 8))

// Тип переменной-указателя на переменную, занимающую 2 байта.
typedef WORD * pWORD;

//--------------------------------------------------------------------------------------------
// Тип переменной, занимающей 4 байта (0..4 294 967 296).
typedef unsigned long int DWORD;

// Тип переменной-указателя на переменную, занимающую 4 байта.
typedef DWORD * pDWORD;

// Макрокоманда получения значения младшего слова двойного слова.
#define LO_WORD(dword) (WORD)(dword)

// Макрокоманда получения значения старшего слова двойного слова.
#define HI_WORD(dword) (WORD)((DWORD)(dword) >> 16)

// Макрокоманда формирования значения типа DWORD из двух значений типа WORD.
#define MAKE_DWORD(lo, hi) (DWORD)(((WORD)(lo)) | ((DWORD)(hi) << 16))

//--------------------------------------------------------------------------------------------
// Тип переменной, занимающей 8 байт.
typedef unsigned long long QWORD;

// Макрокоманда получения значения младшего двойного слова четверного слова.
#define LO_DWORD(qword) (DWORD)(qword)

// Макрокоманда получения значения старшего двойного слова четверного слова.
#define HI_DWORD(qword) (DWORD)((QWORD)(qword) >> 32)

// Макрокоманда формирования значения типа QWORD из двух значений типа DWORD.
#define MAKE_QWORD(lo, hi) (QWORD)(((DWORD)(lo)) | ((QWORD)(hi) << 32))

// Тип переменной-указателя на переменную, занимающую 8 байт.
typedef QWORD * pQWORD;

//--------------------------------------------------------------------------------------------
// Тип переменной-счетчика секунд.
typedef DWORD SECONDS_CNTR;

Извиняюсь, что вклиниваюсь.
Для переносимости кода. Потому, что компиляторы пишут обычно как можно ближе к стандарту языка программирования. А препроцессоры по большей части не стандартизованы (исключая может быть лишь #define и #include). И то, что работает на одном, не обязательно поймет препроцессор другого компилятора. Кроме того, препроцессор не проверяет типы данных и соответственно, оперируя его командами, можно допустить такие ошибки, которые потом "вылавливать" дольше и сложнее.

Правильно мучают.
Стиль действительно странный, не упирайтесь в него. Попробуйте переписать.

Для арифметики гораздо удобнее объявить типы с короткими именами, и которые будут говорить сами за себя:

...
IMNHO, совсем неубедительно. Именно перепроцессором разруливаю проекты на AVR (IAR/GCC) и LPC (RVDMK/IAR), имеющие общий API. Полезные макросы пишутся, естественно, так, чтобы портировалось корректно, очень многие функции параметризуются макроопределениями по шаблонам. На работе препроцессора завязано очень много, при этом несовместимости как-то не наблюдается

Уже были и неоднократно пояснения почему typedef предпочтительнее #define. Пользуйтесь поиском. Вот, например, одна из недавних веток обсуждения http://electronix.ru/forum/index.php?showt...&hl=typedef

Есть замечательная книга Алена Голуба "Правила программирования на С\С++". Небольшая, где на доходчивых примерах описываются разного рода "тонкости" (авторские). Так там рекомендуется использовать препроцессор только тогда, когда это необходимо. Объясняется все просто: код, активно использующий препроцессор сложно читать, сопровождать и отлавливать ошибки. И, имхо, с этим трудно не согласиться

Спасибо, но я неплохо понимаю, что такое typedef, ну и когда может быть полезно применить #define. Если рассматривать только typedef и #define, то в основном соглашусь с Вами. Только какое это имеет отношение к переносимости кода?


Если использование макроопределений, скажем, явно избыточно, не используются правила образования имен, то соглашусь. Также замечу, что без достойного инструмента, позволяющего "ходить" по коду не только по функциям и переменным, но и по макроопределениям, отлаживаться также может быть затруднительно. Но, если нотации определены и их придерживаются, а инструмент заточен, то всё путём.

Спасибо, Ребята! Дисскусия разворачивается хорошая, ну и огромное спасибо автору кода!
Правда нету определения in и out.

Попробуй таки найти текстовым поиском "#define IN" и "#define OUT"
или "отбросить" их как нечто ненужное
#define IN
#define OUT
у меня, например, в кейле используется
#define __flash
чтобы код из IAR не трогать

А вот на такое безобразие препроцессор сругаться должен. Вообще-то #undef для этих целей существует

Вот и найдётся
А #undef существует для случаев когда точно знаешь, что нужно нечто переопределить. Сложнее переопределить чего-нить типа
typedef enum bool{
false = 0,
true = -1
};

Дык

и всех делов
Вот именно что "сложнее", потому и надежнее.

Гы Мне код перебивать не нужно. Мне как раз единожды написанное под яром нужно не править - у меня текст один для кейла и яра, а ненужные квалификаторы просто выбрасываются после разруливания

Тут в примере особо изощренный случай. Такое "надёжное" лучше бы не попадалось вовсе. Пример наглого использования умолчаний Си
bool is_leap(int year){
if(!(year%400))return true;
if(!(year%100))return false;
if(!(year%4))return true;
return false;
}
int Get_Days_In_Month(int month, int year){
return(Days_Array[month]+(month==2)?is_leap(year):0);
}
при таких объявлениях bool просто веселит

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

Правда, я лично использую его неправильно, надо отучаться...
Для маленьких проектов, например, для микроконтроллеров типа АВР, разницы никакой, но привычка переносится и на большие, а там проявляются все эти кажущиеся надуманными проблемы.

Простите, но кем и где не рекомендуется? В стандарте?

ИМХО, это больше зависит от стиля написания и принятого механизма проверок.
ЗЫ Во встраиваемых устройствах до недавнего времени довольно часто приходилось экономить ОЗУ при достаточном объёме памяти программ. Грамотное использование препроцессора позволяет более рационально использовать память программ, высвобождая ОЗУ.

Пишем, пишем...
Объявляем трехэтажный мат #define func_type_macro(arg1,arg2,arg3) .....
Применяем объявленный трехэтажный в 10-ти этажной конструкции нужное количество раз. В куске кода, размер которого никого не испугает.
..........................................
Отменяем #undef func_type_macro

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

Уже неоднократно на эту тему проходились, повторять не охота, воспользуйтесь поиском.

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

Отсутствие анализа контекста несет еще косяки - недавно обсуждали: например, фирма IAR ввела для некоторых новых чипов AVR макроопределения в заголовочных файлах ioxxx.h типа



Теперь, если пользователь использует где-то внутри, в недрах функций (да хоть в списке аргументов прототипов) простое короткое имя N или C, то все, привет. Причем, в ряде случаев весьма неочевидно, в чем ошибка. И хорошо, если еще компилятор заругается на что-то, а то ведь может и прокатить компиляция, а в железе не работает. Вот тут попляшешь с бубном. А все потому, что препроцессор работает тупо и кладет на пространства имен, контекст выражения и делает свою работу скрытно.

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




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

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


А вот мне не приходится. И все получается. Приходится применять только в рамках вышеописанного - для условной компиляции и простых подстановок при портировании.

Псевдонимы типов прекрасно решаются с помощью typedef, о чем уже сказали.

Макросы-литералы замечательно заменяются настоящими типизированными константами. При этом никакого оверхеда не возникает - если нет попытки взять адрес константного объекта или завести ссылку на него, то компилятор не будет его размещать в памяти. Правда, это относится к С++, где у констант по умолчанию внутреннее связывание. Но, думается, сегодня уже нет проблем использовать плюсатый компилятор. В случае с С для получения такого же поведения константные объекты придется обзывать дополнительно static.

Макросы-функции без проблем заменяются встраиваемыми (inline) функциями. Это на сегодняшний день штатно умеют уже не только С++, но и С компиляторы. По Стандарту.

Если требуются какие-то нетривиальные вычисления и надо, чтобы они гарантировано производились на этапе компиляции (во избежание оверхеда), то существует мнение (и я его придерживаюсь), что такие вещи лучше вообще выполнять внешними инструментами и подсовывать компилятору уже готовые значения (потому как компилятор - не калькулятор). Через опцию -D, либо вообще поместив их в отдельный файл, который включается в проект. При использовании систем сборки (make, scons) технических трудностей не возникает никаких. Да и с оболочками тоже проблем во многих случаях нет. В любом случае не слишком разумно заставлять пыжиться целочисленный препроцессор с его 32-битной арифметикой - он отомстит (что часто и происходит).

Если все это вас не убедило, поищите в сети мнение авторитетного дяденьки Б.Страуструпа (автора языка С++), возможно, он подробнее объяснит.

typedef struct TYPE{
......
......
......
} TYPE

TYPE var;
......

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

Простите, но что искать? По слову макрос? Я тут довольно часто, но мимио видно всё интересное по теме пробежало.

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

А вот тут начинается полный субъективизм. Обратный пример - неинициализированные элементы структур и, как самые приятные варианты, неинициализированные указатели на функции и использование указателей на структуры в качестве формальных параметров функции. Необходимость выдерживать порядок инициализации приводит к ещё более "подлым" ошибкам, чем жесткое конфигурирование с использованием макроподстановок (ну нет шаблонов в Си). Но, ИМХО, всё это имеет право на использование, если это не самоцель.

К сожалению, это, IMHO, более желаемое, чем действительное. const переменная это все-таки переменная.

опять же всё субъективно. Если не понимать ограничений препроцессора, то можно и в самом простом ошибиться. (Я, например, для редких случаев сложных константных выражений применяю тесты на интерпретаторе Ch)


К сожалению, есть.


Аналогично
#define else ;

Пример winavr


Ну не хочу я стока писАть !!!



Интересует субъективное мнение:
оправдано ли в данном случае применение макро?

Я расскажу интересное! Не далее как вчера час искал отсутствие фигурных скобок в макросе из двух команд, который использовался в if /else. На фоне какой-то непонятной потери синхронизации с JTAGом повеселился по полной программе. Сам себе клоун.

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

Но создавать такое в каждом проекте - упаси Бог.

Для того, чтобы было понятно, о чем разговор, пример текста описания переменных.
В поддержку протокола в объект 'system' включаются 4 переменных со своими именами, и функциями, вызываемыми при чтении и записи. Все это разворачивается в массивы строк и указателей на функции.
Добавление переменной в протокол происходит за минуту максимум.

Еще добавлю примерчик


Winavr сделает a='A' , поскольку array[0] рассматривается как константное выражение.
Сделают ли то же самое компилеры с услужливым сервисом "чтения флеша" - не уверен.

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


Вернее - это констатный объект. Если нет необходимости размещать его в памяти (не берется адрес и нет ссылки на него), то никакой вменяемый компилятор этого делать не будет - именно для этой возможности в том же С++ специально ввели правило, согласно которому константные объекты имеют внутреннее связывание... Хорошо, не верите, давайте проверим. Поскольку тут форум по AVR, то на нем и будем тренироваться. Код:



Комилятор - какой-то от IAR. v4.хх. Не суть важно. Результат:



Как видим, все замечательно получилось, ничего в памяти не размещается, никаких обращений к памяти, ессно, нет. Это в режиме ++. Отключаем его - в С режиме результат:



Да, тут, как и положено, константа 'a' размещена в памяти (и инициализатор тоже съест свою часть в сегменте инициализаторов), потому что компилятор не имеет права этого не сделать - в С константные объекты имеют по умолчанию внешнее связывание и к ним может производиться обращение из других единиц компиляции. В этом случае линкер будет материться на отсутствие объекта.

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

Поведение можно сделать как в ++ варианте, снабдив объявление констатны квалификатором static:

static const int a = 10;

Результат аналогичен первому варианту:



Думается, что написать ключевое слово 'static' не является слишком обременительным.

Кстати, сделать в С++ поведение констант аналогичным С-шному можно сделать с помощью объявления их как 'extern'. Результат компиляции приводить не буду, поверьте, оно точно соотвествует вышеприведенному С без 'static'.


И в чем они состоят? Для AVR хоть коммерческий IAR, хоть безплатный AVR-GCC давно уже поддерживают почти все фичи С++ (за исключением тяжелых, которые реально применять на AVR смысла нет).

Дальше бессмысленно обсуждать - лучше/хуже, видно/невидно и применять/не применять, рекомендуется/нерекомендуется суть разные вещи.

для начала вменяемые компиляторы не будут ругаться на передачу в качестве фактического параметра функции const переменной, когда формальный параметр объявлен не const. В "прямоугольных" вариантах применения (таких как Вы показали) действительно интеллект компилятора может быть на высоте.

Вы не поверите - использую описанные Вами приёмы и не стесняюсь

Насчёт одинаково хорошо
http://www.klen.org/Projects/Embeded-gnu-t...last_build.html
http://www.klen.org/Projects/Embeded-gnu-t...gcc-cpp-how.txt
А насчёт нюансов использования, например, смотрим пост 7
http://electronix.ru/forum/index.php?showt...;p=247899&#
Не то, чтобы я против использования плюсов - этим нужно заниматься(С)
Но как раз реализации "плюсовости" у компиляторов гораздо более различны, нежели отклонения в работе их препроцессоров.

Не следует путать приятное с полезным. В одном случае имеем объективные трудности из-за использования низкоуровневого кодирования, которое требует повышенного внимания - это сродни кодированию на ассеблере, за всем надо внимательно следить. Обратная сторона этого - высокая эффективность (малый размер, быстродействие) кода. В другом случае сами себе раскладываем грабли. Которые можно обойти, используя более адекватные средства, получив результат не хуже. Каждый случай использования препроцессора должен быть четко обоснован, и на основании этого сделан вывод, что иные пути дают худший результат или вообще не дают такового.



Вы про это:



?

Если да, то вот результат:



Никакой ругани нет. И это не странно, если подумать и понять, что компилятор вполне адекватно оценивает ситуацию и не видит ничего опасного в таком вызове функции. Да и что тут может быть опасного? Ведь передача аргумента делается по значению. Вот если бы была попытка передать указатель (или ссылку) на константный объект, то это была бы ошибка, т.к. такая ситуация может привести к попытке изменить констатный объект внутри вызываемой функции. Но компилятор этого и не разрешает. А если какой-то компилятор разрешает, то это просто его баг и ничего более. Все эти правила стандартизованы и исходят из здравого смысла.

Что не так?


Хорошо, покажите свои "треугольные" или "круглые" варианты, где в подобной ситуации (с константами) компилятор облажается. Давайте пример в студию, посмотрим его. Интересно.


Тогда не понятно, какую точку зрения отстаиваете.


И что конкретно там не так? Я никакого криминала не увидел. Особенно, в части константных объектов - там вообще ни слова не нашел про это. Может, плохо искал?


И что? Манглинг имен - обычное дело в С++, жить реально не мешает. И опять совсем не понял, как это мешает использовать константные объекты вместо макросов?


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

Как правило препроцессор идёт отдельным исполняемым файлом и/или у компилятора есть соответствующий ключик "выполнить только препроцессор".
И можно получить выход препроцессора и всё поразглядывать.



Да, очень много чего можно затолкать в enum-ы, inline-функции и т.п.
Да, в С++ есть ссылки, позволяющие уменьшить использование указателей и связанных с неправильным их применением ошибок (ударение на слове "неправильным", а не на слове "применением"). И т.д. и т.п.
Но, извините,
#define TRUE FALSE
и
#define SQR(x) x * x
это примеры вредительского и безграмотного применения макросов, а не их генетической ущербности.
Но на их базе строится рекомендация "использование макросов следует уменьшать в идеале до нуля", что, на мой взгляд, неправильно, как неправильны и рекомендации не использовать указатели (а почему тогда в стандарте оставили не только условную компиляцию, но и функциональные макросы, склейку и подстановку аргументов и оставили указатели?)

Так же как и с goto, который я использую редко и на форумах иногда сам привожу примеры, как можно обойтись без goto и при этом и сгенерированный код не растёт, и читаемость улучшается, но который я инода таки использую - так же и с макросами:
Используйте, не бездумно, голова дана именно для выбора нужного средства языка!
(Кстати, а какое средство языка можно использовать бездумно? Знаменитые примеры "индусского" кода написаны и без макросов, и без gotoи часто вообще на яве, изначально "лишённой недостатков С/С++")
Правильно и в нужном месте применённые макросы, на мой взгляд, только улучшают (не слишком хорошо формализуемый и очень вкусовой параметр) читаемость кода. Кончено, для людей, умеющих с ними обращаться (та же проблема с указателями).
Огрызок .h


Огрызок .cpp


И не говорите мне, что этот текст надо переписать без макросов для облегчения чтения и сопровождения (представим себе, что понадобилось добавить ещё одну функцию из dlportio.dll и/или изменить обработку ошибки - в каком случае надо больше до-/пере-писывать руками и где при этом больше шансов ошибиться в одной из ветвей - в варианте с макросами или с прямым текстом?

И ещё пример на эту тему

http://www.telesys.ru/wwwboards/mcontrol/1...es/314290.shtml

Очень интересная дискуссия развернулась. Но, в общем то, у меня действительно иногда хомуты с макросами происходят. Хотя, безусловно, это чисто мои ошибки в связи с неустоявшимися (для меня) правилами применения. (Как я считаю). На данном этапе не планирую отказываться от этого средства языка. Возможно потом пересмотрю данное решение.

В связи с этим вопрос. Как в IAR просмотреть результаты работы препроцессора. Например где можно увидеть результаты вычисления констант? В ряде случаев это реально помогло бы.

одним из авторитетов для меня является Герб Саттер,ну, там ещё куча умных опытных людей, которые много поработали с БОЛЬШИМИ системами и знают, какова цена тех или иных ошибок при отладке и сопровождении проектов, создаваемых коллективами за длительные сроки и большие деньги

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


Да, такое средство очень кстати и меня не раз выручало. Ключик:

Project->Options->C/C++ compiler->Preprocessor-> галочка Preprocessor output to file. Только результатов вычисления там не будет - вычисляет компилятор в процессе оптимизации. Можно завести глобальную переменную и присвоить ей значение макроса, а дальше смотреть в листинге какое значение в эту переменную заносится.

Не знаю о чём Вы, но я о том, что заявления, что что-то НЕ РЕКОМЕНДУЕТСЯ, стОит подкреплять не столько личным мнением/опытом (нисколько не умаляю Ваших достоинств), сколько какими либо ссылками на Стандарт.


Я считаю, что препроцессор - нужный и полезный инструмент. Да, огульное его применение не приветствуется, так как существует много описанных выше причин, по которым возникают ошибки. Я для супа использую ложку, а для бифштекса - нож и вилку. Я могу объяснить, почему вилкой есть суп не получится, но мне трудно объяснять ребёнку, почему нельзя есть бифштекс ложкой.
typedef и применение текстовых замен действительно очень похожи, и если нужен тип, то typedef предпочтительнее, чем текстовая подстановка, но ведь не просто так - они отличаются - свойства у typedef имеются, которых у текстовых подстановок нет. Препроцессор позволяет манипулировать с именами (склейка, подмена, удаление, индексация), что при отсутствии поддержки шаблонов на уровне самого языка является необходимым дополнением. Что касается сложных выражений, то применение препроцессора ограничено его ограниченными возможностями и он действительно не предупреждает о переполнениях и прочих глупостях. Но сложность бывает разная - где мы в уме считаем, где не прочь в столбик, а где и калькулятора не хватает. Потому рекомендации по отказу от применения препроцессора при любой возможности считаю необоснованными.

Что касается константных объектов приведу пример, который говорит в пользу препроцессора как удобного инструмента
Это выдаёт ошибку в IAR

Наверно правильно выдаёт


п.6.10
http://upload.caxapa.ru/standards/ansi_c-i...c_9899-1999.pdf


Отдельное спасибо

Ну в такой формулировке - с указанием где именно и без абсолютной категоричности - можно согласиться :-)
Но ведь обычно идёт разговор "запретить и всё тут, так как это источник ошибок".
Так человек, не разобравшийся в понятиях "побочный эффект" и "точка следования" рано или поздно накосячит с применением операторов ++, -- и ещё найдёт где. Но ведь никто не рекомендует отказаться от них и начать писать p = p + 1; Или уже рекомендуют?

Это где такое правило? В GCC? Рад за него. В IAR с некоторых пор появился ключик. А вот в используемом мной сейчас VDSP такого удовольствия нет (не нашел). Т.ч. тут как повезет.


Именно! И все, что можно туда затолкать, не надо пихать в макросы. Об этом и спич.


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


Как насчет вышеприведенного примера про


?

А ведь это не лохи какие-то делали, а вполне серьезная и уважаемая фирма IAR Systems, которая выпускает очень достойные продукты. Замечательные грабли. Замечательный пример той же самой деструктивной мощи. Да, препроцессор обладает известной гибкостью в силу своих свойств по текстовой подстановке, но это палка о двух концах. Не стоит злоупотрелять ею.

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


Да. Но идеал недостижим. Поэтому препроцессор останется.


Потому, что для нее нет адекватной замены.


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


Указатели из другой оперы, не надо все в кучу валить. Еще спроси (ехидно так), зачем оставили ассемблер - там тоже можно при невнимательном обращении наворотить.



Реально есть одна ситуация, где без него геморно - выход из вложенного цикла. Вроде все, больше не знаю (навскидку). Из-за этого оный оператор и оставили в языке.


Осталось найти, как добраться до головы иаровских разрабов, соорудивших макросы, приведенные выше. Если есть возможность разложить грабли - они будут разложены. Раньше или позже, чаще или реже. Желательно, чтобы это было реже. Для этого использование препроцессора надо свести к минимуму, о чем только и речь. Никто не призывает отказаться от него вообще - это, повторяю, нереально. Чего в крайности кидаться.


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


Это большой вопрос, как лучше, пример не убеждает. Насчет руками - про рефакторинг слышал? Кроме того, тут пример очень осторожного использования - определение макроса лежит прямо тут же, все перед глазами. Но не дай бог кто-нить вздумает использовать такое же имя _DL_PTR в своей программе. Будет удивлен. Т.ч. тут тоже есть, что обсудить.


Это где это сказано, что "запретить" и все тут? Сказано было, свести к минимуму.

Да фиг с ними, с разработчиками. Ну достучишься, и "миллионы строк кода уже написанного, отлаженного и работающего кода сразу перестанут компилироваться" Добавлять сразу после #include <ioavr.h>
Кстати, эти же грабельки перекочевали и в заголовочники avr-libc.

Во-первых, "как правило" != "существует правило", во вторых, из правил есть исключения.
Необходимость выдавать ассемблерный листинг тоже нигде не прописана, но как правило эта возможность имеется.
На моей памяти большинство компиляторов позволяли просмотреть выдачу препроцессора.


Ну что я скажу... У gcc в этом месте SREG_I, SREG_N и так далее.
Солидная фирма, не солидная - а бывает и на старушку прорушка.


Я спросил не "почему условную компиляцют оставили", а "почему вместе с ней оставили функциональные макросы, склейку, ..."

Какого кода??? С++ ?
А какого лешего компилировать С-код С++-компилятором?
Или тогда решили, что всё, С-компиляторы больше никто не будет писать и даже развивать, и поэтому для сопровождения С-кода надо в С++ оставить явно вредные вещи? Могли бы в С++ режиме и устранить "огромный недостаток". Тем более, что в мелких, неочевидных и местами обидных случаях С++ таки сильно отличается от С (например, литерал 'я' в языке С имеет тип int а в С++ имеет тип char).


А где ассемблер в стандарте языков С/С++ ???


Так в том-то и дело, что агитаторы за предельную минимизацию применения указателей а то иногда и тернарной операции говорят то же самое - "неочевидно, непонятно, в отличие от массивов, ссылок и if/else". И часто при этом столь же категоричны, как и в случае с goto - "не должно быть вообще", "по нашему стандарту предприятия goto запрещены". Так что кидаюсь в крайности не я.


Это как - я добавляю в описание класса поле, а в конструкторе сразу по кнопочке "сделайте мне красвиво" сгенерируется для него
Или всё же придётся ручками это делать?


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

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


Разве? Там ведь в common.h сидят SREG_*
Хотя, мне кажется, желание "облегчить переход с IAR" у них инода избыточное, могли и добавить односимвольные.

Самостоятельные препроцессоры "C" не редкость, да и тем-же GCC прогнать можно... Посему на везение уповать совсем незачем .



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



Рекомендуют С полгода назад на форуме проскаивала ссылка на переводную статью по "правильному стилю" именно с такой рекомендацией. У многих сей опус вызвал одобрение . Я естественно, не мог смолчать - возражал...

А мне так понравилось. По сравнению с Паскалем, к примеру.

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

Всётаки выбор - великое дело. Зачем самих себя ограничивать изначально. Сталкиваешься с граблями (своими), анализируешь, применяешь так, чтобы в дальнейшем не наступать. Так свой подход вырабатывается. А написание прог для совместного использования, или для постороннего использования, - всётаки сложная задача требующая своих подходов. Я, чаще всего, заимствованное переписываю под себя.

Тем не менее, с учётом данной дискуссии, сделаю выводы и обдумаю все ваши предложения. Попробую переосмыслить. А то действительно проблемы некоторые уже возникали. А всётаки было бы неплохо иметь элемент языка, который бы определял константы под которые гарантированно не выделяется память и которые вычисляются строго на этапе компиляции. Для IBM, экономия памяти не стоит как задача, а вот для мелкоAVRов былобы неплохо.

Анафема тому Паскалю, который не поддерживает функции inc(N,M), dec(N,M)
А насчет пред/пост инкремента, например, действительно генератор граблей. Но пользоваться приятно... до тех пор, пока есть уверенность в адекватной трансляции.

Delphi'сты рекомендуют


Я еще люблю применять
#define K 1024
#define M K*K

Просто кому придет в голову объявить переменную ОДНОЙ ЗАГЛАВНОЙ буквой?


++ / -- - просто создан для индексации массивов.
тоже неплохо смотрится в условиях.

а повсеместно тыкать ++ / -- ни ни, я отдаю предпочтение p += 1 вместо ++;

Они сишникам не указ, и даже не авторитет.

Тут можно спорить о возможном несовпадении (один из них или оба могут не польностью соответствовать стандрату и проверка одним другого будет неадекватной). Но в целом он чаще есть, чем его нет. Я их даже эпизодически прикручивал для своих нужд (например, в pldasm какие-то кусочки пихал для облегчения написания).


Это если говорить о сложившейся ситуации. И я тоже так делаю иногда, хотя и inline-функции, и объявление переменных по месту, включая счётчики в циклах for - есть в C99, просто до сих пор не все поддерживают. Да и в С99 есть не менее вкусная возможность инициализировать элементы структур/массивов по имени, в С++ этого нет. Так что... Где найдёшь, где потеряешь...

А если говорить на момент "до того", когда язык С++ только сбивался и ещё и люди не привыкли пользоваться "С-совместимыми" расширениями С++, и "массы текстов" не набралось, то кто мешал "таки повыкидывать из С++ тяжкое наследие С, не приносящее ничего, кроме вреда"?
По поводу смешанных проектов - никто не мешает весь С-текст держать в отдельных файлах, компилировать в С-режиме со всеми функциональными макросами, а потом линковать с С++ - программой, скомпилированной в С++ режиме.
Ввели бы для условной компиляции что-то как-бы похожее, но интегрированное в язык, а не являющееся отдельным проходом. Как результат в условии компиляции можно было бы применять и enum-определённые константы и т.п. Кто мешал? И не было бы споров Ну скучал бы я по старым добрым макросам


Где? Как?
Может, генератором граблей есть голова пишущего, не разобравшаяся в побочных эффектах и точках следования?
Если так, то надо требовать изменения консти стандарта С таким образом, чтобы все переменные по умолчанию были volatile, так как от непонимания этого момента "глюков" ещё больше.
Ну или просто компилировать свои программы с выключенной оптимизацией.



Шаманим потихоньку?

Стандарт С:



++E эквивалентно E+=1 всегда
любое из них эквивалентно E = E + 1 в подавляющем большинстве случаев.
Разница будет, например, для a[i] += 1; в случае, когда i объявлено как volatile, иначе выражения семантически эквивалентны.

Это я в курсе
Дело принципа и привычки, от ++ в глазах рябит. Как и написал выше ++/-- использую только для индексации и в условиях:

while( zz--)
{
*p++ = xx;
p[ idx++] = xx;
}
...

а когда стоит вопрос одинокого инкремента какой-то переменной или указателя то пользую

p += 1;

Ну как же? локальную переменную типа char для цикла в puts так и хочется обозвать заглавной C.