#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

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

[Valentine Logino...]

Inline-функции, как было сказано, позволяют сделать меньше ошибок: проверка типов + отладка в пошаговом режиме. Всегда можно вспомнить пример про вызов макроса MAX(a++, .

Как сделать в виде функции макрос ТС зависит от того как определены PORTA, PORTB etc. Скорее всего static inline void GpioConf(GPIO_TypeDef port, uin32_t...) {...}. Не?

[ViKo]

Как сделать в виде функции макрос ТС зависит от того как определены PORTA, PORTB etc. Скорее всего static inline void GpioConf(GPIO_TypeDef port, uin32_t...) {...}. Не?

Немного некомфортно, что inline функцию нужно вставлять в заголовочный файл *.h, а не в *.c. Чтобы ее можно было использовать в другом файле.
А сколько переменных можно передать в функцию? ничего не треснет?

[zltigo]

Немного некомфортно, что inline функцию нужно вставлять в заголовочный файл *.h, а не в *.c. Чтобы ее можно было использовать в другом файле.

А что, с макросами как-то иначе . Смущает .h? так назовите .c - какие проблемы?

А сколько переменных можно передать в функцию? ничего не треснет?

Треснет - стек, если его размера не хватит для размещения всех передаваемых переменных.

[ViKo]

А что, с макросами как-то иначе . Смущает .h? так назовите .c - какие проблемы?

Э-э, себя-то не обманешь... include так include. Я не говорю, что прямо воротит, просто не тем цветом в Notepad++ раскрашивает.

Треснет - стек, если его размера не хватит для размещения всех передаваемых переменных.

Там не будет использоваться стек, эти переменные заменяются макроопределениями.

Код

/*! GPIO Mode Type */
typedef enum {
  MD_IN,            //!< Input *
  MD_GO,            //!< General purpose output
  MD_AF,            //!< Alternate function
  MD_AN                //!< Analog  
} GPIO_MODE_t;
и т.д.

Я так думаю.

[zltigo]

Э-э, себя-то не обманешь... include так include. Я не говорю, что прямо воротит, просто не тем цветом в Notepad++ раскрашивает.

Не понимаю в чем обман.

Там не будет использоваться стек, эти переменные - макроопределения.

Вы это как-бы подумайте, прежде, чем такое писать. Функции глубоко безразлично, она по любому получает переменные в стеке или/и в регистрах.

[ViKo]

Функции глубоко безразлично, она по любому получает переменные в стеке или/и в регистрах.

Сейчас макрофункция инициализации порта компилируется в ~14 команд (+ память для констант):

CODE

inline void GPIO_init(void)
{
/* Биты 0..7 порта A используются для чтения RL, нужно подтянуть к GND */
GPIO_CONF(A,
MD_IN, OT_PP, SP_LO, PL_PD, AF_00, // 0: RL0
MD_IN, OT_PP, SP_LO, PL_PD, AF_00, // 1: RL1
MD_IN, OT_PP, SP_LO, PL_PD, AF_00, // 2: RL2
MD_IN, OT_PP, SP_LO, PL_PD, AF_00, // 3: RL3
MD_IN, OT_PP, SP_LO, PL_PD, AF_00, // 4: RL4
MD_IN, OT_PP, SP_LO, PL_PD, AF_00, // 5: RL5
MD_IN, OT_PP, SP_LO, PL_PD, AF_00, // 6: RL6
MD_IN, OT_PP, SP_LO, PL_PD, AF_00, // 7: RL7
MD_AF, OT_PP, SP_ME, PL_NP, AF_02, // 8: TIM1_CH1 - FCAL
MD_AF, OT_PP, SP_HI, PL_NP, AF_01, // 9: USART1_TX -> FPRX
MD_AF, OT_PP, SP_LO, PL_NP, AF_01, // 10: USART1_RX <- FPTX
MD_GO, OT_PP, SP_ME, PL_NP, AF_00, // 11: L3V
MD_GO, OT_PP, SP_ME, PL_NP, AF_00, // 12: L12V
MD_AF, OT_PP, SP_ME, PL_NP, AF_00, // 13: SWDIO
MD_AF, OT_PP, SP_ME, PL_NP, AF_00, // 14: SWCLK
MD_GO, OT_PP, SP_HI, PL_NP, AF_00); // 15: FREQ-

CODE

GPIO_init PROC
;;;194 */
;;;195 inline void GPIO_init(void)
000000 2009 MOVS r0,#9
;;;196 {
;;;197 /* Биты 0..7 порта A используются для чтения RL, нужно подтянуть к GND */
;;;198 GPIO_CONF(A,
000002 4912 LDR r1,|L80.76|
000004 06c0 LSLS r0,r0,#27
000006 6001 STR r1,[r0,#0]
000008 2200 MOVS r2,#0
00000a 8082 STRH r2,[r0,#4]
00000c 4910 LDR r1,|L80.80|
00000e 6081 STR r1,[r0,#8]
000010 4910 LDR r1,|L80.84|
000012 60c1 STR r1,[r0,#0xc]
000014 6202 STR r2,[r0,#0x20]
000016 21ff MOVS r1,#0xff
000018 3113 ADDS r1,r1,#0x13
00001a 6241 STR r1,[r0,#0x24]

И что, inline функция такого не осилит сотворить?

[CrimsonPig]

Сейчас макрофункция инициализации порта компилируется в ~14 команд (+ память для констант):

Ну так попробуйте и нам расскажите
Не, понятно, что вы дочитали книжку до описания inline функций и пытаетесь всунуть их теперь куда нужно и не нужно. Не волнуйтесь, все этим занимаются по началу
Хотите еще занятие на полгода примерно ? Почитайте про шаблоны в Ц++ и попытайтесь переписать свой код инициализации на рекурсивных шаблонах и прочей радости
Это можно сделать.. некорорые даже это делают. Нормально получается у единиц, и никто не пользуется в результате

[ViKo]

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

Я не волнуюсь. Вам же повторю "Если нечего сказать, не говори ничего."

[CrimsonPig]

Я не волнуюсь. Вам же повторю "Если нечего сказать, не говори ничего."

Спасибо вам за совет. Идите.... в гугль, там вам место