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, не переживай браток. Просто С++ это не твоё.

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

С != С++