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

[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);

Спасибо.

[Lem]

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

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

[ReAl]

как во что разворачивается макроопределение выяснить практически нереально (достоверно)

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



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

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

Код

typedef WINAPI void (*DlPortWritePortUchar_t) (unsigned port, uint8_t d);
typedef WINAPI uint8_t (*DlPortReadPortUchar_t) (unsigned port);
typedef WINAPI void (*DlPortWritePortBufferUchar_t) (unsigned port, const uint8_t *pd, int len);

class lpt_dlportio_t : public lpt_io_t
{
public:
    lpt_dlportio_t(unsigned _base);
    ~lpt_dlportio_t();

    virtual uint8_t read(rd_offset offs);
    virtual void write(wr_offset offs, uint8_t d);
    virtual void write_data(const uint8_t *pd, int len);

private:
    HINSTANCE hdlportio;
#define _DL_PTR(_f_) _f_##_t _f_##_P
    _DL_PTR(DlPortWritePortUchar);
    _DL_PTR(DlPortReadPortUchar);
    _DL_PTR(DlPortWritePortBufferUchar);
#undef  _DL_PTR
}; // class lpt_dlportio_t

Огрызок .cpp

Код

lpt_dlportio_t::lpt_dlportio_t(unsigned _base)
    : lpt_io_t(_base), hdlportio(NULL)
{
    hdlportio = LoadLibrary("DLportIO.dll");
    if (hdlportio == NULL)
        throw error_win32_t(E_INVHARD, "Can't load port access library `DLportIO.dll'");

#define _DL_LOAD(_f_)\
        do {\
            _f_##_P = (_f_##_t)GetProcAddress(hdlportio, #_f_);\
            if(_f_##_P == NULL)\
                throw error_win32_t(E_INVHARD, "Can't load port access library `DLportIO.dll'"); \
        } while(0)

    _DL_LOAD(DlPortWritePortUchar);
    _DL_LOAD(DlPortReadPortUchar);
    _DL_LOAD(DlPortWritePortBufferUchar);
#undef _DL_LOAD

} // lpt_dlportio_t::lpt_dlportio_t

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

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

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

[dxp]

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

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

Да, очень много чего можно затолкать в enum-ы, inline-функции и т.п.

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

Но, извините,
#define TRUE FALSE

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

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

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

Код

#define I 7
#define N 2
#define C 0

?

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

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

Но на их базе строится рекомендация "использование макросов следует уменьшать в идеале до нуля",

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

(а почему тогда в стандарте оставили не только условную компиляцию,

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

но и функциональные макросы, склейку и подстановку аргументов

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

и оставили указатели?)

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

Так же как и с goto, который я использую редко

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

так же и с макросами:
Используйте, не бездумно, голова дана именно для выбора нужного средства языка!

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

(Кстати, а какое средство языка можно использовать бездумно? Знаменитые примеры "индусского" кода написаны и без макросов, и без gotoи часто вообще на яве, изначально "лишённой недостатков С/С++")

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

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

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

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

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