Стиль программирования на Си, описание функции Опции

[sKWO]

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

Код

void Stop_Timer(IN IDX timer);

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

Код

/*--------------------------------------------------------------------------------------------*/
/* Процедура остановки таймера.                                                               */
/* Принимает:   номер таймера (0 - 7).                                                        */
/* Возвращает:  ничего не возвращает.                                                         */
/*--------------------------------------------------------------------------------------------*/
__monitor void Stop_Timer(IN IDX timer)
{
  Timer[timer].Timer_Ena = TIMER_DIS;
  return;
}

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

Код

void Start_Timer(IN IDX timer, IN WORD interval, IN pTIMER_FUNC pFunc = NULL, IN bool cycle = TIMER_ONCE);

Спасибо.

[sensor_ua]

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

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

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

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

[dxp]

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

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

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

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

Код

#define N 2
#define C 0

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

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

Код

#define TRUE FALSE // счастливой отладки, суки

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

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

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

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

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

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

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

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

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