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

[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]

Но это, повторяю, другое

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

никакой вменяемый компилятор этого делать не будет

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

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

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

И в чем они состоят?

Насчёт одинаково хорошо
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&#
Не то, чтобы я против использования плюсов - этим нужно заниматься(С)
Но как раз реализации "плюсовости" у компиляторов гораздо более различны, нежели отклонения в работе их препроцессоров.

[dxp]

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

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

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

Вы про это:

Код

const int a = 10;
int b;

int g(int x, int y);

int main()
{
    g(a, b);
}

?

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

Код

int main()
        main:
{
    g(a, b);
....               LDI     R30, LOW(b)
....               LDI     R31, (b) >> 8
8120               LD      R18, Z
8131               LDD     R19, Z+1
E00A               LDI     R16, 10
E010               LDI     R17, 0
........           CALL    ??g
}

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

Что не так?

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

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

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

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

Насчёт одинаково хорошо
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...=247899�

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

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

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