Вот именно потому, что я объяснил, она будет именно одна. Потому что линкер создаст связь всех обращений к переменной к одной и той же, по причине того, что символ имеет одно уникальное имя, несмотря на то, что определен "150 раз" через инклудник.

Да, действительно, одна получается.

Выходит, что определение inline функции в h-файле - то же самое, что объявление extern inline h-файле и определение в с-файле.
Добавление static к функции делает статическую переменную локальной.

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

Вот нашел еще:
http://stackoverflow.com/questions/216510/...e/216546#216546

in K&R C or C89, inline was not part of the language. Many compilers implemented it as an extension, but there were no defined semantics regarding how it worked. GCC was among the first to implement inlining, and introduced the "inline", "static inline", and "extern inline" constructs; most pre-C99 compiler generally follow its lead.

GNU89:

"inline": the function may be inlined (it's just a hint though). An out-of-line version is always emitted and externally visible. Hence you can only have such an inline defined in one compilation unit, and every other one needs to see it as an out-of-line function (or you'll get duplicate symbols at link time).
"static inline" will not generate a externally visible out-of-line version, though it might generate a file static one. The one-definition rule does not apply, since there is never an emitted external symbol nor a call to one.
"extern inline" will not generate an out-of-line version, but might call one (which you therefore must define in some other compilation unit. The one-definition rule applies, though; the out-of-line version must have the same code as the inline offered here, in case the compiler calls that instead.

C99 (or GNU99):

"inline": like GNU "extern inline"; no externally visible function is emitted, but one might be called and so must exist
"extern inline": like GNU "inline": externally visible code is emitted, so at most one translation unit can use this.
"static inline": like GNU "static inline". This is the only portable one between gnu89 and c99

Жестко! А где ее взять? Написать отдельно в не-инлайн версии?

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

Мутно, конечно, это. Как я понял, лучше всегда писать static inline, от греха подальше.

Куда-то топик унёсся не туда. Хотелось бы увидеть лог компилятора, а не "весёлые картинки".
На первом сообщении видны реальные матюги компилятора или просто ненормальности Эклипса ?
Он часто в последние годы тупит, пытаясь быть самым умным, но не имея на это достойной поддержки своих "разумных" авторов, "обнимающих необъятное" в IT-областях.
У меня большинство файлов не обходятся без его "меток", хотя в реале всё компилируется без вопросов.

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

А можно взять Keil IDE но использовать arm-none-eabi
Там проще всё
Или VisualGDB и VisualStudio
И не мучится с armcc.exe
А что в конференции на keil.com или arm.com говорят ?

Сообщение отредактировал x893 - Feb 5 2015, 15:37

А толку то? От смены компилятора вдруг чудесными образом в рамках тех же исходников самоопределятся __ASM и __INCLUDE ?

arm-none-eabi к синтаксису проще относится. То что там проходит - в armcc может быть warning или даже error.

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