Зачастую в проекте нужен не просто механизм создания отчётов, а ещё и механизм создания отчётов из шаблонов, да и чтобы в редактируемом виде, так что ход мысли в статье верный. Был такой проект docxfactory, кроссплатформенный на c++, к сожалению заглох. Я его форкнул _https://github.com/bas524/Docxfactory, сделал сборку через cmake. Собирать сложно, но можно. Поддерживаются шаблоны в формате docx, используются только открытые библиотеки, работает в продакшене под Win и Linux.
Я же указал тему — это enterprise edition конкретно для C++, так что язык программирования тут имеет значение. И проблема, которую я обозначил, кратко звучит так: «В C++ нет стандарта/спецификации аналогичной JavaEE, но хотелось бы, а пока её нет, то вот варианты реализаций отдельных библиотек, похожих на C++EE».
Конечно JavaEE, как платформа, имеет дефолтовые реализации всех спецификаций, но не запрещает их поменять. Так что Вы правы отчасти. А наивные приложения зависят от библиотек, так что все аналогично Java, только на другом уровне.
Действительно, многие так поступают, перепысывая с плюсов на что-то ещё, с более богатым рантаймом, но это не всегда приемлемо, яркий тому пример — это любое ПО, подвергающееся сертификации, что в России, что в Европе, его нельзя писать не на компилируемых языках, если есть хоть намёк на гриф информации, так вот в этом случае от плюсов не уйти просто. Может пример узковатый получился, но показательный, есть и другие примеры из медицины, например,…
Спецификаций действительно нет, а вот решений есть, особенно востребовано это в системах с высоким уровнем защиты и сертификации, т.е. там, где можно только компилировать и нельзя интерпретировать, и нельзя виртуальных машин. Я как то уже отписываться о СЭД Министерства Обороны, так вот там все на c++ и это очень даже Enterprise, теперь, я работаю на антивирусную компанию, и тут тоже c++, который дополнен своим Enterprise Edition. Т.е. и в СЭД и в антивирусе есть разная реализация одних и тех же сущностей, естественно выборка моя не ограничивалась двумя компаниями, их было больше, и общая картина такова, что все мы делаем одно и тоже, только разными способами.
То, что есть в JavaEE по умолчанию тоже не всех устраивает, но есть стандарт и имплементацию можно заменить, предоставив тем самым гарантии совместимости.
Безусловно, плюсы — универсальный язык, но, к сожалению, его стандартная библиотека не покрывает некоторых "универсальных" потребностей, которые я назвал c++ee. Фреймворки предоставляют эти возможности, но заставляют тянуть паровозом то, что может и не надо, так что хочется стандартизации того, что есть во всех фреймворках.
Никаких "своих" фреймворков я и не предлагаю. Я говорю о том, что текущий "открытый" стандарт языка c++ не описывает некоторые сущности, например, логгер или application, а хотелось бы. А в статье собраны реализации того, что хотелось бы в c++ee.
в с++ есть просто «стандарт» и нет особого смысла разбивать его на подмножества наборов спецификаций отдельных фич
Но ведь стандарт не определяет понятия Applicaton или Logger, а этим пользуются. И то, что нет «стандарта» только добавляет боли поиска решения. Текущий же стандарт он не про «сериализацию», DSL и подобное, текущий стандарт — это про базовые контейнеры и алгоритмы. И я не «за подмножество наборов фич», я за типовые решения в рантайме языка, ну или где-то очень рядом, например в бусте.
У меня три сына… Просто возьми мои деньги…
В посте про Qt, на который Вы сослались использовался Qt5, а у Вас Qt4. Все-таки разница существенная, может сделаете 2й заход?
Зачастую в проекте нужен не просто механизм создания отчётов, а ещё и механизм создания отчётов из шаблонов, да и чтобы в редактируемом виде, так что ход мысли в статье верный. Был такой проект docxfactory, кроссплатформенный на c++, к сожалению заглох. Я его форкнул _https://github.com/bas524/Docxfactory, сделал сборку через cmake. Собирать сложно, но можно. Поддерживаются шаблоны в формате docx, используются только открытые библиотеки, работает в продакшене под Win и Linux.
@cppee, коллеги, присоединяйтесь к каналу в телеграмм.
Конечно JavaEE, как платформа, имеет дефолтовые реализации всех спецификаций, но не запрещает их поменять. Так что Вы правы отчасти. А наивные приложения зависят от библиотек, так что все аналогично Java, только на другом уровне.
Действительно, многие так поступают, перепысывая с плюсов на что-то ещё, с более богатым рантаймом, но это не всегда приемлемо, яркий тому пример — это любое ПО, подвергающееся сертификации, что в России, что в Европе, его нельзя писать не на компилируемых языках, если есть хоть намёк на гриф информации, так вот в этом случае от плюсов не уйти просто. Может пример узковатый получился, но показательный, есть и другие примеры из медицины, например,…
Прошу прощения, не дописал и отправил…
Продолжу… О том, что свой DSL — одна из типовых задач, а способ реализации — выбор каждого
Соглашусь, олдскульно, но тут мысль о том что DSL
Спецификаций действительно нет, а вот решений есть, особенно востребовано это в системах с высоким уровнем защиты и сертификации, т.е. там, где можно только компилировать и нельзя интерпретировать, и нельзя виртуальных машин. Я как то уже отписываться о СЭД Министерства Обороны, так вот там все на c++ и это очень даже Enterprise, теперь, я работаю на антивирусную компанию, и тут тоже c++, который дополнен своим Enterprise Edition. Т.е. и в СЭД и в антивирусе есть разная реализация одних и тех же сущностей, естественно выборка моя не ограничивалась двумя компаниями, их было больше, и общая картина такова, что все мы делаем одно и тоже, только разными способами.
Безусловно, этими гарантиями должен являться стандарт, который может гарантировать совместимость, например, на уровне интересов.
То, что есть в JavaEE по умолчанию тоже не всех устраивает, но есть стандарт и имплементацию можно заменить, предоставив тем самым гарантии совместимости.
Безусловно, плюсы — универсальный язык, но, к сожалению, его стандартная библиотека не покрывает некоторых "универсальных" потребностей, которые я назвал c++ee. Фреймворки предоставляют эти возможности, но заставляют тянуть паровозом то, что может и не надо, так что хочется стандартизации того, что есть во всех фреймворках.
Тогда JavaEE — это фреймворк?
Никаких "своих" фреймворков я и не предлагаю. Я говорю о том, что текущий "открытый" стандарт языка c++ не описывает некоторые сущности, например, логгер или application, а хотелось бы. А в статье собраны реализации того, что хотелось бы в c++ee.
Но ведь стандарт не определяет понятия Applicaton или Logger, а этим пользуются. И то, что нет «стандарта» только добавляет боли поиска решения. Текущий же стандарт он не про «сериализацию», DSL и подобное, текущий стандарт — это про базовые контейнеры и алгоритмы. И я не «за подмножество наборов фич», я за типовые решения в рантайме языка, ну или где-то очень рядом, например в бусте.
Вы правы, я и сетую на то, что нет такого же стандарта для c++, а есть лишь реализации.