суть задачи

есть необходимость написать библиотечные 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, нет?

Barlonenojavaно такое дармовое контрактное условие выполняется/проверяется не всегда, потому у разработчика должен быть выбор.
Выбор == возможность облажаться
А так еще забавный момент - в С++ переполнение для signed - это неопределенное поведение (в отличие от unsigned). Причем эти грабли совершенно реальны . Так что даже проверить наличие знакового переполнения кроссплатформенно затруднительно.

затруднительно, но не невозможно - см. выше про intsafe.h и gcc builtin-ы

возможность облажаться есть всегда - даже в Java с их хваленым "GC решает все проблемы" память точно так-же течет, как и везде, ну а вместо dangling pointer они отхватили свои классы системных проблем

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

так-то в лужу можно сесть всегда вон на простейшем: http://blog.regehr.org/archives/1307, где даже -Wstrict-aliasing не помогает :(

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

в debug режиме (O0) это все, естественно, не работает
А вы уверены, что ваши __inline__ в исходнике как-то попадают объектный файл и влияют на решение линкера? Может, просто поставив ключи для link time optimization, вы получите то же самое?

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

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

maytonnojavaа avg() это отдельная тема, и NULL во float/double вроде как принято представлять через NaN, нет?
Нет. Арифметика с Infinity/Nan - это все части стандарта IEE 754 и других (тысячи их). Я знаю что
JavaScript весьма лукавым образов вводит полиморфизм decimal-типов используя double но
и имеет артефакты. Точно не уверен (не специалист в JS) но кажется только индексы массивов
кастятся в целое а все остальные вычисления арифметики идут через double.


да, в JavaScript вообще все числа по-умолчанию double, там чтоб как-то подсказать JITу, что это integer - нужно делать еще те приседания.

maytonstd::ratio Тоесть нам нужна биекция между доменом значений NUMBER и нашим типом данных
на стороне клиента.

std::ratio это вообще не про это подсчет денег, это для теоретизированых математик, это вообще мимо кассы со страшным грохотом

http://en.cppreference.com/w/cpp/numeric/ratio/ratio_add

Anatoly Moskovskynojavaсо временем будет опубликовано на github, пока не время :)
Чувствую, когда придет время, Стебелек будет повержен

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

maytonnojavaпропущено...


std::ratio это вообще не про это подсчет денег, это для теоретизированых математик, это вообще мимо кассы со страшным грохотом

http://en.cppreference.com/w/cpp/numeric/ratio/ratio_add
Для nested set может пригодится.
http://www.sql.ru/forum/1151532-1/tyapnichnyy-nested-set

листая подобное, понимаешь - насколько они далеки от народа (с)

а всего-то навсего хотелось вариацию на тему Pro*C

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



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

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

ИзопропилBagaBagaпропущено...

А я-то губу раскатал :) Три года ждать? :))
к 2020 вроде обещвно

а я что, виноват? в этом вашем C/C++ все блин как-то сделано через одно место (в сравнении с той-же Delphi или Java).

Хочется допустим в релиз тиснуть развертывание стрека (stacktrace функция, файл, номер строки) при exception, как это сделано в Java, и понеслась - stackwalker.cpp, backtrace() и прочие чудные костыли, 100500 опций компилятора, которые хрен пойми как тискать в эти ваши cmake конфиги, просто чтоб получить striped debug info (не показывать кастомеру излишнее).

Причем каждая платформа имеет свои, особо зверские костыли в вопросе, тот-же Mac OS X 10.9 и выше вообще backtrace() разучился понимать, OpenBSD его никогда и не понимал, а в Solaris как всегда свои косяки с addr2line, и... а всем до лампочки.
Скажано - stacktrace не нужен, сиди втыкай в coredump, ага (который у клиента не включен, ясен пончик).


Вон заставить заработать инлайнинг - тоже нужно блин целое исследование три дня делать, изучать всякую ерунду вроде golden блин linker для clang с плагинами и прочие приседания сделать. ABI несовместимости для .so - следующий квест, и т.д.

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

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

Уже давно бы перешел, только он не кроссплатформенный :(

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

Anatoly MoskovskynojavaКаждый казалось бы простой вопрос - как привинтить ту или иную фичу кроссплатформенно
Нужда в кроссплатформенности сильно преувеличена.
Больше всего стоит разработка и поддержка софта.
А платформу можно подогнать под софт какую надо. Стоит это копейки по сравнению.

сильно, не сильно - это до лампочки. есть понятие sanity check - если ты что-то можешь сделать только в MSVC или в GCC, то сто пудов ты это делаешь не так.

типичный пример - макросы TODO, которые через pragma message бросают сообщение при билде, которые потом засасывает jenkins и т.п.

попробуй сделать это так, чтоб понимало





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

просто потому что они ни разу не пытались свои "солющины" сделать именно кроссплатформенными

maytonnojava, не переживай браток. Просто С++ это не твоё.

конечно С++ это не мое, программировать на возведенной в абсолют копипасте (это я про темплейты), это пожалуйста пройдите к другому эскулапу.

С != С++