#define FUNCTION() vs. inline Function(), второе более "модно", а почему? Опции

[ViKo]

Собственно, весь вопрос в заголовке темы. Помню фразы, что в C++ роль макроопределений много меньше, чем в C. Стало быть, надо ориентироваться на inline функции?

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

Код

__forceinline void FpRq_off(void)
{
  GPIOA->BSRR = FPRQ_H;
}

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

Код

#define DELAY(VALUE, UNIT)    \
  DelayFourCycles(((VALUE) * UNIT * (SYSCLK / 1000000) + 3999) / 4000)

#pragma push
#pragma O3
__forceinline void DelayFourCycles(uint32_t FC)
{
__asm {
LOOP:
    SUBS FC, FC, #1
    BNE LOOP
  }
}
#pragma pop

Хочу просветления. Или уже...?

[dimka76]

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

Может конечно есть и еще что-то более существенное, но я не знаю.

[zltigo]

С инлайн фукциями проще искать ошибки.

Точнее СЛОЖНЕЕ сделать ошибки. Других причин нет. Но для простейших задач все инлайновские обертки ничего, кроме кучи мусора для глаз, не дают.

В Watcom C...

Ого! Кто-то, кроме меня, еще помнит и пользует Watcom? Я до сих пор массу всяких утилиток на Watcom пишу - традиция, да и под Linux сразу из под Win собираются, ибо линукс дано похерил, но иногда нужно бывает.