Форум РадиоКот

Объявляю функцию как inline void в прототипе пишу extern inline void
в одном проекте все работает перенес библиотеку в другой проект
компилятор IAR выдает ошибку. убираю модификатор inline все находит (делаю вывод что файл header подключается нормально)

Даже не знаю в какую сторону копать.

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

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

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

Ps: прогнал на самой высокой оптимизации не в одном варианте функцию не вывернул.

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

Как вариант - extern, а вместо функций - макросы в хидере.

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

Близко к истине, но не так. В оригинале значится: "By declaring a function inline, you can direct GCC to make calls to that function faster."
На всякий случай перевод: "Объявляя функцию inline, вы указываете GCC сделать вызовы этой функции быстрее".
В некоторых случаях, данная функция действительно может оказаться в коде, а не в виде отдельной подпрограммы. Например, если она вызывается с одинаковым набором параметров или всего один раз.
extern - это указание компилятору, что данный идентификатор внешний, доступный для обработки LD. Так как любая не статическая функция, с кодом в текущем файле, является внешней то, запись
int func(int i) { return i++;}
и запись
extern int func(int i) { return i++;}
имеют один и тот же смысл, так как если функция не статическая, то значит она внешняя.

А вот сочетание этих extern и inline в одном месте может действительно привести к неожиданным последствиям.
Подробности: https://gcc.gnu.org/onlinedocs/gcc/Inline.html

pokk писал(а):Даже не знаю в какую сторону копать.

В сторону понимания сущности inline. И немного в сторону понимания того, как работает трио препроцессор-компилятор-линкер. Первый лепит из *.h и *.c большие простынки *.(ну скажем pp) и скармливает их компилятору. На выходе компилятора появляется *.o - файл со скомпилированными объектами. Линкер собирает согласно списка все объектные файлы в программу - устанавливает связи (linker- ведь!) между объектами, попутно проверяя все ли ссылки из модулей находят объекты в других модулях и однозначны ли эти связи. Если компилятор изыскивает возможность реально заинлайнить функцию - то как объект в модуле она существовать не будет - и попытка заставить линкер связать вызов из других модулей на такую функцию закономерно обломится.
Таким образом реконструкция катастрофы выглядит следующим образом - предыдуший компилятор толи не решился функцию инлайнить, то ли решил, что раз она объявлена в заголовке [???] то программист по ходу "не сечёть фишку" и добро-бы перестраховаться - создал её "в теле". IAR же или по упёртости или по жестоковыйности своей натуры возжелав наказать "неряху" - заинлайнил функцию, спихнув на линкера ответственность разгребаться в связях [подобно пьяному дьячку на колокольне].
Что делать - учиться програменному делу настояшим образом ©, знать и любить свой инструмент как солдат лопату. static, inline - это не ускоряющие заклинания, а конкретные требования к компилятору - который в общем-то тупой исполнитель нашей воли. Т.е. если inline функция, грубо говоря, слегка подобна макросу - и пользоваться сей "макрос" будет в нескольких единицах компиляции (т.е. препроцессорных простынях собранных из С-файлов) то помещать его хорошо туда где его все увидят - т.е. в файл заголовка. НО! Как уже замечалось выше - компилятор порою избирательно туп и если он откажется инлайнить функцию, определённую в заголовке, - то у линкера появятся претензии иного рода - к наличию множественных копий её тела в разных объектных файлах. Т.е. мы плавненько возвращаемся к первому предложению этого абзаца - понимание того как работают инструменты позволит расшивать ситуации на лету вне зависимости от причуд конкретного компилятора.

добавлю еще об inline: эта директива не принуждает компилятор обязательно инлайнить тело функции, это лишь рекомендация сделать это, если подвернется возможность (или необходимость). а вот какие там возможности или необходимости будут - это отдано на откуп компилятору, ему и решать. для гарантированного инлайна применяются всякие костыли (вероятно, разные для разных компиляторов). например, AVR-GCC должен всегда инлайнить функцию, для которой задан атрибут always_inline.

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

Ну.. строгих правил на этот счёт нет, но я предпочитаю что-то вроде переменная и функция вроде как и одинаково выглядят, но функция хорошо по скобкам видна.

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

FreshMan писал(а):Кто какую использует форму записи макроса, дабы в проге было видно четкое различие между оным, переменной и функцией ?

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

Мурато Мяуконни писал(а):Вы, уважаемые, слишком-то не переусердствуйте с инлайнами то. А то результирующий код ваш будет разрастаться до нев...ных размеров

Уважаемый, кто эти "Вы" ? В упор не вижу, кто усердствует с инлайнами.
Или просто решили чем-то блеснуть, рассказав нам о явно очевидных вещах ?

Не заставляйте компилятор решать за вас, где и как делать.

Как же жить тогда, если нет доверия компилятору ?

Мурато Мяуконни писал(а):Главное, найти для себя наиболее удобную и читаемую схему и следовать ей во всех проектах

полностью подерживаю: единство стиля постоянно - залог успеха.

Мурато Мяуконни писал(а):Макрос, как вариация дефайна (переназначения, замены текста) - целиком заглавными буквами

лично я придерживаюсь иных правил:
1. определение пользовательского типа - всегда с _t на конце, всегда маленькими буквами: point_t
2. описание переменных - всегда маленькими буквами: counter, iteration;
3. функции - всегда маленькими буквами. сложные имена функций составляю из отдельных частей с помощью подчеркивания: some_func();
4. макрос-константа - всегда ЗАГЛАВНЫМИ: F_CPU
5. макрос-функция - всегда по правилу описания функции: some_macro();

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

Кстати, по последнему моменту, когда макрос выглядит как функция.

По идее, можно макрос-функцию назвать MACRO_NAME(), и обернуть её в void macro_name() {MACRO_NAME()}.

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

Аlex писал(а):Как же жить тогда, если нет доверия компилятору ?

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

Ну а про "сообщение очевидных вещей" - эт вы напрасно. Если у меня только 5 сообщений на форуме, это вовсе не означает, что я написал на Си только 5 строчек. Блеснуть я могу много чем, как бы вот...
И кстати, нечего мне тут "минусовать в карму", только за то, что вам че-то не понравилось. По уровню знаний и реализованных проектов я могу и вас переплюнуть, если че как бы вот.

WiseLord писал(а):По идее, можно макрос-функцию назвать MACRO_NAME(), и обернуть её в void macro_name() {MACRO_NAME()}.

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

Мурато Мяуконни писал(а):Ну а про "сообщение очевидных вещей" - эт вы напрасно. Если у меня только 5 сообщений на форуме, это вовсе не означает, что я написал на Си только 5 строчек.

А что это значит ? Что написали 7 строк ? Я не экстрасенс и понятия не имею, сколько, чего и где Вы понаписали.
И причём тут очевидные вещи ? "Ему про Фому, а он про Ерёму"
Вы выскочили, обвинили нас в каком то переусердствовании, рассказав нам очевидность - инлайн функции раздувают код. К чему этот пост был ? Что в нём полезного ?

Мурато Мяуконни писал(а):По уровню знаний и реализованных проектов я могу и вас переплюнуть, если че как бы вот.

Улыбнуло
Смахивает на гонор малолетнего студента, запустившего свои первые часики на МК и бъющего себя в грудь - "Я великий эмбеддер"

Мурато Мяуконни писал(а):И кстати, нечего мне тут "минусовать в карму", только за то, что вам че-то не понравилось

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

ARV писал(а): 1. определение пользовательского типа - всегда с _t на конце, всегда маленькими буквами: point_t

С пользовательскими типами - это да, конечно. _t на конце. Хотя лично я не люблю часто переопределять типы. Единственное - это в структурах.

Добавлено after 3 minutes 42 seconds:

Аlex писал(а):Не стоит мне указывать, что мне делать. Я могу, ненароком, и сказать, куда вам пойти...
Лучше на вопрос ответьте, который я вам задал.

Так-так-так, полегче, полегче. Если вы модератор, то ведите себя подобающе, без хвастовства.
Какой вопрос вы задали? Озвучьте, и я вам обстоятельно отвечу. Если конечно сочту, что вы поймете ответ.
А то, я смотрю, вы всецело доверяете компилятору, и вероятно, не очень то в курсе того, как и что делает компилятор.

ARV писал(а):

WiseLord писал(а):По идее, можно макрос-функцию назвать MACRO_NAME(), и обернуть её в void macro_name() {MACRO_NAME()}.

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

Вообще-то я говорил о том, чтобы макрос вызывался только из этой функции. А уже она - в коде.

P.S. Да, это мало отличается от того, чтобы просто назвать так макрос сразу. Но часто разные IDE не очень хорошо работают с автодополнением кода и прочими "плюшками" в случае использования макросов, особенно когда они окружены разного рода #ifdef/#else и т.п. Поэтому, возможно, "проброс" через функцию ещё и тут поленым оказаться может, тем более, что если у функции есть аргументы, то и подсказки по типам могут полезными оказаться.

Мурато Мяуконни писал(а):Какой вопрос вы задали? Озвучьте, и я вам обстоятельно отвечу.

А вы почитайте повнимательнее. У меня всего один пост был, в нём трудно не заметить вопросительных знаков и вопросительную интонацию.

Мурато Мяуконни писал(а):Если конечно сочту, что вы поймете ответ.

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

Мурато Мяуконни писал(а):ведите себя подобающе

Опять указы
Да Вы, похоже, себя точно каким-то Богом чувствуете. И знаете больше всех, и указываете что кому делать...

Мурато Мяуконни писал(а):без хвастовства

Где вы хвастовство в моих постах увидели ?
На себя не пробовали посмотреть со стороны ?


ЗЫ: Перестаньте набивать себе посты пустозвонным текстом. До хорошего это не доведёт, уверяю вас.

Пустозвонный текст пока что только у вас. К чему были вот эти ваши последние сообщения на этой странице??? Какую полезную инфу они несли? Прочтите их и подумайте.
А если хотите увидеть уровень моей квалификации - посмотрите список моих сообщений, первое мое сообщение на форуме - ответ на оставшийся без ответа вопрос по микроконтроллеру на ядре Cortex M7. У вас есть что сказать по этой теме? Хорошо, добро пожаловать в ту тему - с удовольствием обсудим с вами вопросы реализации обработки потокового видео с камеры разрешением не ниже VGA посредством STM32F746.