Инлайновая функция Опции

[Jenya7]

Если я определяю функцию как инлайн

Код

файл .h
inline uint32_t SYSTIME_GetSystemTime(void);
файл .с
inline uint32_t SYSTIME_GetSystemTime(void)
{  
    //do something
}

то при вызове функции IAR ругается Error[Li005]: no definition for "SYSTIME_GetSystemTime"
то есть функцию надо разместить в .h файле по другому никак?

Сообщение отредактировал Jenya7 - Jul 5 2018, 10:37

[VladislavS]

Начиная с C++11 в каждой новой спецификации добавляются всё новые возможности выполнения кода на этапе компиляции. Это сейчас модно, а не инлайны, с которыми компиляторы уже давным-давно научились сами разбираться. Попереключайте настройки оптимизатора и посмотрите результаты компиляции. Адептам секты пресвятого инлайна смотреть результат оптимизации с ключом Size на максимуме не рекомендую , чтобы при виде сплошного антиинлайна не возникли суицидалные мысли.

Сейчас мэинстрим чтобы программа вообще не порождала run-time кода Модно написать программу на несколько страниц и получить пару ассемблерных команд. Даже соревнования проходят кто больше кода на этапе компиляции выполнит.

И тут очередной такой ТС с давно уже неактуальным инлайном на белом коне въезжает. Совет ТС - если у вас есть место где не проходите по скорости, а иначе зачем гнаться за инлайном, то лучше перепишите этот кусок более оптимально наблюдая за результатом компиляции. Может даже с уходом в ASM. Но надеяться на инлайн не стоит. Даже если вы директиву принудительного инлайна поставите, компилятор может её проигнорировать. Не из вредности, а из-за продвинутости оптимизатора.

Кстати, приёмов оптимизации в арсенале компилятора очень много, но почему-то только инлайн так волнует души неокрепших программистов Почему вас раскручивание циклов вообще не волнует, а?

[jcxz]

Почему вас раскручивание циклов вообще не волнует, а?

Это точно
Мне здесь на форуме один товарищ недавно рассказывал и пытался убеждать, что копирование через memcpy() в любом случае быстрее, чем написать это копирование простым циклом на си. Сколько я ему не намекал, что оптимизирующий компилятор может и этот цикл и даже саму memcpy(!) раскрутить в несколько ассемблерных инструкций (в зависимости от размера пересылки, выравниваний и известности параметров пересылки на этапе компиляции), а может и то и другое заменить просто оптимальным циклом с копированием внутри - так и не убедил его. Он только обиделся. Он приводил в доказательство какие-то частные случаи, в определённых созданных им условиях.
Так он и не понял, что при включении максимальной оптимизации и чем лучше и продвинутее компилятор, тем результат будет больше зависеть от реализуемого действия (алгоритма), а не от способа его реализации (цикл-ли, инлайн или даже memcpy).
Так и ТС здесь - уверен что что-то зависит от того, с inline он напишет функцию или без.
Так что как я неоднократно убеждался - понимание принципов работы оптимизаторов ускользает от основной массы программистов, сколько не описывай это в мануалах. Ну и в результирующий ассемблерный код тоже как видно мало кто смотрит и понимает его. Иначе бы даже без мануалов всё было понятно.

PS: Кстати - вдогонку, в тему: Иногда возникает желание сказать компилятору (IAR в частности), чтобы он не inline-ил функцию. Так это сделать посложнее чем сказать inline.
А вот сделать функцию жёстко "не inline" вне зависимости от работы оптимизатора - это имхо гораздо полезнее чем сделать её inline.

[scifi]

Мне здесь на форуме один товарищ недавно рассказывал и пытался убеждать, что копирование через memcpy() в любом случае быстрее, чем написать это копирование простым циклом на си. Сколько я ему не намекал, что оптимизирующий компилятор может и этот цикл и даже саму memcpy(!) раскрутить в несколько ассемблерных инструкций (в зависимости от размера пересылки, выравниваний и известности параметров пересылки на этапе компиляции), а может и то и другое заменить просто оптимальным циклом с копированием внутри - так и не убедил его. Он только обиделся. Он приводил в доказательство какие-то частные случаи, в определённых созданных им условиях.

Был случай, когда хотелось, чтобы memcpy был маленький и медленный. Скорость не нужна, а байтов жалко. Библиотечный memcpy шибко умный, видимо. Ускоренный настолько, что весит сотни байт :-( Хоть заменяй своим.

PS: Кстати - вдогонку, в тему: Иногда возникает желание сказать компилятору (IAR в частности), чтобы он не inline-ил функцию. Так это сделать посложнее чем сказать inline.
А вот сделать функцию жёстко "не inline" вне зависимости от работы оптимизатора - это имхо гораздо полезнее чем сделать её inline.

Очевидно же: взять адрес функции, загнать его в указатель volatile, не? И вызывать через этот указатель для верности.

[jcxz]

Был случай, когда хотелось, чтобы memcpy был маленький и медленный. Скорость не нужна, а байтов жалко. Библиотечный memcpy шибко умный, видимо. Ускоренный настолько, что весит сотни байт :-( Хоть заменяй своим.

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

Очевидно же: взять адрес функции, загнать его в указатель volatile, не? И вызывать через этот указатель для верности.

Не уверен что это прокатит с любым компилятором. Да, указатель он создаст, и пожалуй даже поставит команду LDR Rx, указатель. Но кто дальше ему мешает просто вставить код функции? Ведь все условия volatile указателя он уже выполнил: создал его, и чтение его выполнил.

PS: Про #pragma inline=never знаю и его сейчас и использую в IAR. Но это компиляторо-зависимо.

[scifi]

Но кто дальше ему мешает просто вставить код функции?

Как кто? Вызов функции по указателю volatile. Он же не знает, что там в этом указателе (он же volatile!), поэтому именно вызовет функцию по указателю без всяких инлайнов. И заметьте, это чистый Си, без всяких прагм и атрибутов.

[jcxz]

Как кто? Вызов функции по указателю volatile. Он же не знает, что там в этом указателе (он же volatile!), поэтому именно вызовет функцию по указателю без всяких инлайнов. И заметьте, это чистый Си, без всяких прагм и атрибутов.

Да, в текущей версии IAR это работает, но нет уверенности, что будет также работать и в последующих.
В доках насчёт volatile говорится только применительно к данным, про код ничего не упоминается.

Немного погуглив нашёл _Pragma(...)

Код

#ifdef IAR
        #define NO_OPT _Pragma ("optimize=none")
#endif

Ну так это совсем не то. Это как бороться с перхотью при помощи топора
Тогда уж так: #define NO_OPT _Pragma("inline=never")

[scifi]

Да, в текущей версии IAR это работает, но нет уверенности, что будет также работать и в последующих.
В доках насчёт volatile говорится только применительно к данным, про код ничего не упоминается.

Это уже паранойа какая-то. Так можно в чём угодно усомниться
Впрочем, я не настаиваю, куйте своё счастье самостоятельно