Определение inline функции, Обязательно в хедере? Опции

[sonycman]

Есть несколько файлов исходника:
LCD.h с объявлением функции:

Код

inline    void    lcdClearScreen();

LCD.c с определением:

Код

inline    void    lcdClearScreen()
{
    lcdWriteCommand(0x01);
};

и вызов этой функции из третьего файла I2C.c:

Код

#include    "lcd.h"
...
lcdClearScreen();

Что-то первый раз столкнулся с тем, что, при компиляции файла I2C.c, компилер выдаёт ошибку про отсутствие определения этой функции
Вышел из положения включением определения функции в хедер LCD.h:

Код

inline    void    lcdClearScreen()
{
    lcdWriteCommand(0x01);
};

Получается, inline функции необходимо определять сразу при объявлении?

[Сергей Борщ]

Получается, inline функции необходимо определять сразу при объявлении?

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

[sonycman]

А, понятно
То есть компилер за один проход должен создать объектный файл? А для не-встраиваемых внешних функций, определённых в других файлах, генерируются простые обращения в виде вызовов, а уже линкер потом записывает конкретные адреса?

Спасибо!

[Сергей Борщ]

То есть компилер за один проход должен создать объектный файл? А для не-встраиваемых внешних функций, определённых в других файлах, генерируются простые обращения в виде вызовов, а уже линкер потом записывает конкретные адреса?

Да, именно так. Причем для встраиваимых функций и обращений не будет. Все тело будет вставлено туда, где для обычной функции был бы вызов.

[Rash]

возникла таже проблема, но так и не понял как её решить.
Можно пример кода, где и что объявлять?

[_Артём_]

Можно пример кода, где и что объявлять?

Объявлять можно в h-файле

Код

#define LED_PORT PORTB
#pragma inline=forced
inline void LedOn() {
    LED_PORT|=(1<<LED_PIN);
}

или так:

Код

#define PRAGMA(x) _Pragma( #x )
#define INLINE PRAGMA( inline=forced ) static

INLINE void LedOn() {
    LED_PORT|=(1<<LED_PIN);
}

[Rash]

спасибо, т.е. тело функции должно быть в h файле?
Может можно сделать что бы inline объявления были в h, а реализация в С файлах

[_Артём_]

т.е. тело функции должно быть в h файле?

Может быть и в с-файле:

Код

#pragma inline=forced
inline static void OffLed()
{
    PORTD.DIRSET=1;
    PORTD.OUTCLR=1;
}


int main() {
    OffLed();

Может можно сделать что бы inline объявления были в h, а реализация в С файлах

У меня такое сделать не получалось (а зачем оно надо?): линкер ругается чем то наподобии "Undefined OffLed". Видимо это неспроста.

[Rash]

У меня такое сделать не получалось (а зачем оно надо?): линкер ругается чем то наподобии "Undefined OffLed". Видимо это неспроста.

Да не получается. Перепробовал наверное вариантов 20, так и не нашёл как.
Удобно в С файлах код, а в h описание ф-ций.

[Dog Pawlowa]

Да не получается.

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

[VladislavS]

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

[Rash]

не знаю проблема или нет, но я хотел бы видеть вой код так:

описание инлайн функции в файл1.h, код выполнения в файл1.с, а вызов функции, т.е. её встраивание было в файл2.с.

[Сергей Борщ]

не знаю проблема или нет

Проблема. Потому что во время компиляции файл2.c компилятор понятия не имеет ни о существовании файл1.c, ни о его содержимом и, соответветственно, о том, что же именно ему нужно вставить в место вызова этой функции. Чтобы он имел возможность встроить, тело функции должно быть ему доступно, а значит располагаться либо в файл2.c, либо в любом файле, включенном в него директивой #include. Других вариантов нет.

Хотите красоты - делайте функцию невстраиваемой. По этому пути пошли создатели CMSIS. В ней, чтобы записать одно значение в один регистр вызывается функция со всеми вытекающими тормозами и раздутием кода.

[_Артём_]

Хотите красоты - делайте функцию невстраиваемой. По этому пути пошли создатели CMSIS.

Это красота?
В CMSIS полно inline-функций.
В чём неправильность их пути?

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

А как лучше делать?

[aaarrr]

А как лучше делать?

Лучше просто писать в регистр.

[_Артём_]

Лучше просто писать в регистр.

Как просто...
А почему они не пишут "просто в регистр"?

[aaarrr]

А почему они не пишут "просто в регистр"?

От большого ума, надо полагать. Увы, вижу массу примеров, как на пустом месте создается "библиотека", бессмысленная и беспощадная. CMSIS - как раз один из таких случаев.

[AHTOXA]

Мне кажется, тут разные люди говорят о разных CMSIS-ах. Та часть, которая от собственно ARM - она состоит вообще исключительно из *.h файлов с инлайн-функциями и определениями структур. (Это файлы core_cm0.h, core_cm3.h, core_cm4.h, core_cm4_simd.h, core_cmFunc.h, core_cmInstr.h.) Остальное - это уже от производителя конкретного контроллера. И здесь уже конечно бывают навороты
Кстати, ST здесь на удивление скромны - всего-лишь startup_xxx.s и system_xxx.c. Остальное - опять же хидеры. Зато уж в своей StdPeriph библиотеке они уже оторвались по полной

[_Артём_]

Зато уж в своей StdPeriph библиотеке они уже оторвались по полной

И не только они: NXP, EFM - тоже самое делают.

[aaarrr]

Кстати, ST здесь на удивление скромны - всего-лишь startup_xxx.s и system_xxx.c. Остальное - опять же хидеры. Зато уж в своей StdPeriph библиотеке они уже оторвались по полной

Мне хватило просмотра кода вычисления делителя UART - остальную часть библиотек ST забраковал не глядя.

[AHTOXA]

Мне хватило просмотра кода вычисления делителя UART - остальную часть библиотек ST забраковал не глядя.

Да, это шедевр Но это не CMSIS, вот я о чём.

[scifi]

Мне хватило просмотра кода вычисления делителя UART - остальную часть библиотек ST забраковал не глядя.

+1. STишная библиотека вызывает стойкое отвращение.
Причём особого смысла в её существовании не вижу: руководство по МК всё равно нужно читать, а для облегчения программирования регистров можно придумать очень небольшой набор макросов. Регистры МК довольно понятные. А в сложных случаях (таймеры) попытка сделать обёртку для упрощения может всё только запутать. Лучше в руководстве всё подробно расписать.

[Dog Pawlowa]

STишная библиотека вызывает стойкое отвращение.
Причём особого смысла в её существовании не вижу

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

[aaarrr]

Да, это шедевр Но это не CMSIS, вот я о чём.

Дык, в CMSIS тоже всплывают косяки периодически.

...подергался-подергался и работаю с библиотекой.

У меня были такие мысли, пока окучивал USB на STM32F40x. Сделано как будто специально, чтобы максимально неудобно софт писать было