суть задачи

есть необходимость написать библиотечные inline- функции (имеется в виду статическая библиотека).

т.е. код для инлайнинга должен лежать в .lib, это важно, не в .h

вариант делать как обычно - дефиницию помещать в .h не подходит, т.к. функции тянут за собой довольно тяжелые внешние зависимости, которые в целевом проекте не нужны (чтоб не портить ctags/intellisense и прочий автокомплит).
ну и не разрешать девелоперу просто так юзать третьесторонние фичи без спросу.

в visual c++ удалось подобное запинать через __inline __forceinline и обязательный /GL с /LTCG (кроссмодульно инлайнит только на линковке, иначе никак инлайниться не пожелало).

в GСC же получился какой-то явный brainfuck с __attribute__ ((gnu_inline)), возврат к GNU89 семантике как-то показался сильно подозрительным. в Solaris Studio аналогично - свои чудные бубенцы с флагами обратной совместимости. до других компиляторов руки еще не дошли.

собственно вопрос - у кого-то есть пример как надо правильно и кроссплатформенно делать сабж? пример библиотек? компиляторы - последних-предпоследних версий. усиленный гуглеж в течение суток убедительных примеров не дал.

и желательно еще и случай .dll/.so, хотя последние не обязательны (они используются только для ускорения линковки при разработке, там все равно debug режим, а релиз собирается целиком статическим блобом)

Anatoly MoskovskyА если попробовать LTO как описано здесь?
http://stackoverflow.com/questions/5987020/can-the-linker-inline-functions

c GCC опциями компилятора проблем нет, там проблема в том, что inline атрибут на функцию указывается немного через одно место - в соответствии c С99/C11 стандартами, с выплевыванием куч warning и прочими малопонятными не покрытыми внятной документацией приседанями.

кучерявыми макросами и научным тыком все это конечно решается, но осадок сырости остался.


меня больше интересовал вопрос как это в принципе нужно грамотно делать, на примере существующих решений, вроде APR, QT и подобных библиотек, в проекции на все актуальные компиляторы.

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

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

да да, ты еще скажи, что между O0 и O3 на современных процах разницы нет.

задача явного управления инлайном - это просто ограничение маневра анализатору - а то он там сам наанализирует.

Anatoly MoskovskyНу и вот эта мотивация очень специфическая.
Вот тут да, ты прав, там мотивация - сделать из C/C++ среду прикладного, а не системного программирования. Стандартные библиотеки и остальное на прикладные задачи совсем не тянут - попросту неадекватны, потому и должны быть гарантированно выкинуты из доступных.

Такое изначально никому не нужно - мало кто отважится сделать свой "еще один Objective C"

MasterZivinline не могут быть библиотечными.
Либо inline, либо библиотечные.


MasterZivНикак. это невозможно.

твое мнение очень ценно для нас (с)

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

Anatoly Moskovskynojavaда да, ты еще скажи, что между O0 и O3 на современных процах разницы нет.
В вашем случае нет разницы.
Когда функция является оберткой над скрытой имплементацией, то инлайнь ее или нет - пофиг.

вообще-то не пофиг, потому что инлайнится builtin целочисленной арифметики, с проверкой переполнения.
https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html#Integer-Overflow-Builtins
и аналогичные интринзики из MVCC https://msdn.microsoft.com/en-us/library/windows/desktop/ff516460(v=vs.85).aspx
плюс атомарные builtin , плюс чекалки доступа памяти, плюс...

которые в каждой платформе свои особо кустистые, и делать их обычными функциями - это просад по перфомансу до 50%


а так да - мнение, инлайнить или нет - очень ценное мнение, выскажешь его еще раз?

kealon(Ruslan)nojavaпропущено...

Вот тут да, ты прав, там мотивация - сделать из C/C++ среду прикладного, а не системного программирования. Стандартные библиотеки и остальное на прикладные задачи совсем не тянут - попросту неадекватны, потому и должны быть гарантированно выкинуты из доступных.

Шутник, синтаксис у С++ тоже не совсем адекватен для прикладного проганья
а нативный движок + скрипты для прикладников чем не устраивает?
синтаксис у С++ вполне адекватен, я не говорил обратного.

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

если в Oracle есть свой BCD подобный тип NUMBER, то в C++ есть только IEEE float с потерей точности, за использование которого в финансовых задачах нужно просто брать руки и зажимать их нежно в дверь.

в теории GCC поддерживает decimal float, но по факту - нет. и это мы только по типам данных для денег прошлись, дальше можно и по остальным неадекватностям прогуляться - от ORM, то веб-темплейтов, будет, мягко говоря, не весело, но мне уже немного лень

Anatoly Moskovskynojavaа так да - мнение, инлайнить или нет - очень ценное мнение, выскажешь его еще раз?
Если надо инлайнить - пишите инлайн функции в хедерах и поставляйте их с библиотекой.
Это ответ на ваш вопрос как грамотно делать.

в этом совете нет ни грамма про грамотность, там лишь про типовой общепринятый (и неадекватный в данном случае) подход.

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

каждый раз парсить эти .h при компиляции и делать подобную ненужную работу тоже не хочу (и вот не надо тут говорить еще и про pch, там отдельная смешная печаль в этих ваших фактически некросплатформенных C/C++).

BagaBaganojava,

я крайне сомневаюсь, что у вас получится одновременно extern и inline. Более того, я уверен, что у вас так не получится, чтобы это ещё и реально работало, допустим, под gcc, clang и MS C++ compiler ... а ведь можно ещё про интел вспомнить и Сан Оракл ...

Но если вдруг получится - поделИтесь секретом, ладно?

это уже получилось, в gcc, mvcc, clang, sunpro. никакого секрета нет - везде используется link time optimization, ключи естественно разные, но cmake им вполне можно обучить.
форсирование инлайнинга везде делается по-разному, но чудные макросы INLINE решают и эту проблему.

в debug режиме (O0) это все, естественно, не работает

со временем будет опубликовано на github, пока не время :)

Barlonenojavaвообще-то не пофиг, потому что инлайнится builtin целочисленной арифметики, с проверкой переполнения.
https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html#Integer-Overflow-Builtins
и аналогичные интринзики из MVCC https://msdn.microsoft.com/en-us/library/windows/desktop/ff516460(v=vs.85).aspx
плюс атомарные builtin , плюс чекалки доступа памяти, плюс...

которые в каждой платформе свои особо кустистые, и делать их обычными функциями - это просад по перфомансу до 50%
Да вы просто неправильно язык выбрали, вам не С++ нужен, а то-то другое :)
А вообще проверка переполнения дает просадку производительности, даже если она интегрирована в языке.

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

кроме того, С/C++ по факту наиболее развиты в части оптимизации кода и поддержка в IDE одна из лучших


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

этож основы контрактного программирования. если у тебя в for (int i = 0; i < n; i++) проверка на переполнение встроена уже в i < n, то ясное дело, ее нет никакой нужны делать еще и в i++.

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

а конктерно в контексте выше - проверка на целочисленное переполнение нужна в случае как раз библиотеки для финансовой математики - если в случае double переполнение будет решено просто потерей значимых цифр (без всякого exception), то если делать fixed point number тип для подсчета денег, то переполнение значимых цифр может привести к катастрофе (опять-же, без exception) - а это надо отлавливать и проверять.

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

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

Неожиданное место начинается в безобидном числе 0.3, которое никак не может быть представлено через double/float
даже специальный сайт есть с описанием этого... феномена


http://0.30000000000000004.com/


кстати, даже в Delphi есть специальный тип Currency .
Кстати, реализован именно как Fixed point number, хотя BСD там тоже есть http://docwiki.embarcadero.com/RADStudio/Seattle/en/BCD_Support_Routines

Аналогичная ситуация в .NET

Хотя умудренные опытом мейнфрейм деды говорят не про BCD, а про decimal floating point , который в .NET тоже есть https://msdn.microsoft.com/en-us/library/364x0z75.aspx и примерно подобный в Java http://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html

надо понимать, что BCD != DFP != Fixed point, это разные подходы к точному подсчету денег. А в Oracle NUMBER - это вообще base-100 тип.

самый скоростной и переносимый - fixed point, ибо крутится на integer (int64/int128)


а avg() это отдельная тема, и NULL во float/double вроде как принято представлять через NaN, нет?