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

[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 в своей программе. Будет удивлен. Т.ч. тут тоже есть, что обсудить.

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

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

[ReAl]

Это где такое правило? В GCC? Рад за него.

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

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

Код

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

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

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

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

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

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

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

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

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

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

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

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

Код

нужное_имя = (нужный_тип)GetProcAddress(hdlportio, нужная_строка);
            if(нужное_имя == NULL)
                throw error_win32_t(E_INVHARD, "Can't load port access library `DLportIO.dll'");

Или всё же придётся ручками это делать?

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

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

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

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

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

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

Кстати, эти же грабельки перекочевали и в заголовочники avr-libc.

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