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

А как иначе компилятор получит тело функции для встраивания?

Зачем вам этот инлайн? Включайте в яре "multifile compilation" и оптимизацию, он сам заинлайнит получше любых вот этих потуг.

так он заинлайнит все функции. а мне нужно несколько.


я думал как и обычные функции - из .h файла

Ну это вряд ли, зависит от настроек оптимизации и характера кода. А даже если и все, что за печаль?


Интересно, зачем? Нет, правда интересно.

Свидетели секты пресвятого инлайна.

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



если вам не нужен инлайн то наверно вам можно только позавидовать.

Я Вас уверяю, компилятор может посчитать, что и Вам inline, собственно, не нужен, и не станет вставлять тело функции, а вызовет ее.

Вы как бы даже не задумались, что подобные проблемы здесь на форуме возникают только у Вас? Совсем ни о чём не говорит?

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


Неправда ваша, последователи этой секты появляются с регулярной периодичностью.


Где такую забористую @$# берёте? В IAR поставьте оптимизацию Balanced и забудьте раз и навсегда.

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

и всё

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

Поддерживаю.

Отладить сложно неудобно в макросах, плюс проверка на соответствие типов в макросах отсутствует... ИМХО, не очень удобно. Хотя сам пользуюсь

В основном потому, что инлайн - нестандартное расширение.
Но дело даже не в этом. Вот не могу себе представить, где это реально может понадобиться. Вернее, могу, но это будет оч. экзотический случай. В 99% случаев это можно отдать на откуп современному компилятору. Он умеет инлайнить сам без подсказок, причём функции из разных файлов без тела функции в хедере.

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

использование inline ещё не говорит о том, что функция будет сто процентов инлайниться. Для принудительного инланинга необходимо использования директиву
#pragma inline = forced

Можно пользоваться языком, у которого ключевое слово "инлайн" прописано в стандарте.


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

Результат компиляции функции-макроса, часто порождает более оптимальный код, чем результат оптимизации даже хорошего компилятора - оптимизаторы пока не идеальны.
Да и иногда полезно при отладке (без оптимизации) иметь обязательный инлайнинг. А inline в си к сожалению вещь опциональная - на усмотрение компилятора. По-крайней мере в IAR.
А ещё бывает нужно в качестве аргумента передать несуществующее значение, которое внутри макроса, конкатенируясь, даст реальные переменные/константы. Такой финт с inline-функцией не провернёшь.
А ещё бывает желательно проверять валидность аргументов функции. В обычной функции (или inline) можно сделать такую проверку только с порождением кода и работающую в run-time. В макросе можно сделать проверку в build-time, не порождающую лишнего кода.

Кстати, да. Оно есть в голых Сях уже лет семь.

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

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

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

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

Это же легко: Евгения Онегина в комментарий скопипастить - и дело в шляпе
Есть ещё соревнования по созданию самых непонятным программам: тыц.

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

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

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


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

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


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

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

А в IAR разве нет атрибутов наподобие gcc и keil?
У меня написан compiler.h в котором все нюансы компиляторов запрятаны. Типа

А пользовательский код никаких специфических вещей компиляторов не использует - только свою прослойку.
ИМХО прагмы в коде последнее дело...

Атрибутов не знаю, знаю только прагмы. И тогда Ваш compiler.h - неверный.


Согласен. Но я не знаю другого способа явно указать IAR-у - инлайнить или нет.

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

Не знаю с какой версии, но

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

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


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

То, то.
ИМХО внутри _Pragma(...) можно всё что угодно написать (даже "inline = forced") и задефайнить...

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

В мануале на IAR нет ничего про volatile для указателей на функции. Судя по контексту описания, там везде подразумевается его использование для описания данных. Поэтому и осторожничаю.
Всё-таки про прагму чётко там написано: не будет инлайнится и всё тут.
А как поведёт себя в последующих версия IAR с void (* volatile)() - я не уверен.
Но всё равно - спасибо Вам что указали на такую возможность запрета inline. Мне самому не пришло в голову в своё время.

Не только лишь все умеют иронию.

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

Вы полагаете, что способ предложенный scifi, не только сделает функцию явно не-инлайновой, но и запретит оптимизацию её кода? хмм.... если это так, то тогда этот способ некошерный...

вобщем вдруг осенило. вспомнилвот тебе бабушка и юрьев день инлайн

а впринципе я тут посчитал - что мы экономим на инлайне - 8-10 инструкций - 100-200 наносекунд - наверно это не существенно. разве это спасет отца русской демократии?

Почему оптимизацию-то запретит? Внутри всё заоптимизирует и снаружи тоже, а вот функцию как единицу вызова оставит. Единственное что вызывать её нужно всё таки по указателю, если быть педантичным.

И на каком основании Вы делаете такой вывод? Перечитал в мануале на IAR всё что касается volatile - там ни слова об указателях на функции.

Сильно удивляете. Стандарт на язык читать надо, а не иаровский мануал.

Только без точки с запятой в конце.

Похоже на то, что стандарт не в курсе дела.

Можете привести выдержку из стандартна касательно этого?

Стандарт не обязан разжёвывать каждую ситуацию. Кое-что следует логически из того, что там написано.
У вас опасение, что при вызове функции по указателю компилятор заинлайнит код. Причина, по которой этого не случится: указатель объявлен как volatile, поэтому компилятор не знает, что в нём, поэтому не знает, какой код туда можно заинлайнить вместо вызова функции по указателю. Следовательно, вызовет функцию.

Из описание действия volatile на переменные, следует что компилятор не должен оптимизировать никакие операции с данными через эти указатели.
Соответственно - для указателей на функции можно ожидать, что он не будет оптимизировать и сами функции? Или даже - на всю цепочку функций, вызываемых из данной функции? А это меня не устраивает.


Нет, скорее у меня опасение, что раз это явно не описано в стандарте, то может трактоваться строителями компиляторов так, как они считают правильным.
Это называется "undefined behaviour".


Что значит "не знает"? Для функции есть объявление.
И если подходить логически, то что значит volatile для переменных? Он собственно означает, что порядок и количество операций доступа к данным при использовании volatile в оптимизированном коде должны быть точно такими же как в неоптимизированном. Раз в неоптимизированном коде сперва следует чтение указателя из памяти, значит компилятор при оптимизации не должен удалять такое чтение. Но вот что нельзя удалить пару инструкций BLX Rx/BX LR - это из описания volatile для данных никак не следует. Так как они не выполнят операций с памятью.
volatile накладывает ограничение на выполнение операций с объектом, а не на расположение объекта. Так что ничто не мешает ему расположить этот объект сразу после точки вызова, убрав инструкции передачи управления. Имхо.

Имхо, в случае с указателем на функцию играет роль является ли этот указатель lvalue или нет.

lvalue нельзя инлайнить, а xvalue и rvalue - можно.

Я устал объяснять. Просто скажу, что вы заблуждаетесь.

Не совсем понятно почему такое может быть. Функция на момент компиляции ничего не знает о существовании указателей на неё. Она даже где-то в другом модуле может быть скомпилирована и лежит себе ждёт своего часа. Остаётся взять её адрес и вызвать пока тёпленькая.

{
((void (* volatile)())func)(); // оптимизирует несмотря на volatile. наверное потому, что получаемый указатель rvalue;
}

N3690

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

Отчего у вас в голове родилась странная идея что внутри тела фукнции будет отключена оптимизация я не знаю. Она неверна.


Нет волатайл объекта - нет ограничений. Вот так уже работает.