Comments 47
А вы точно понимаете, что такое Java EE? Это разрозненный набор спецификаций, а не реализаций. В случае Java основный смысл именно в том, что это стандарт.
Вы правы, я и сетую на то, что нет такого же стандарта для c++, а есть лишь реализации.
в с++ есть просто «стандарт» и нет особого смысла разбивать его на подмножества наборов спецификаций отдельных фич
Но ведь стандарт не определяет понятия Applicaton или Logger, а этим пользуются. И то, что нет «стандарта» только добавляет боли поиска решения. Текущий же стандарт он не про «сериализацию», DSL и подобное, текущий стандарт — это про базовые контейнеры и алгоритмы. И я не «за подмножество наборов фич», я за типовые решения в рантайме языка, ну или где-то очень рядом, например в бусте.
Текущий же стандарт он не про «сериализацию»
данные можно сериализовывать миллионом способов
DSL и подобное
ну плюсы всё-таки являются универсальным языком
Безусловно, плюсы — универсальный язык, но, к сожалению, его стандартная библиотека не покрывает некоторых "универсальных" потребностей, которые я назвал c++ee. Фреймворки предоставляют эти возможности, но заставляют тянуть паровозом то, что может и не надо, так что хочется стандартизации того, что есть во всех фреймворках.
Boost.Aplication? Orchestartor? Busines?
Извините, дальше вытекли глаза и не смог читать.
Какой ужас.
Ещё один не понял, что язык программирования это не реализация а стандарт, в случае с++ — можно считать публичный.
А статья пытается название этого стандарта приватизировать под какой-то конкретный программный продукт. Нехорошо так делать.
Если б это назвалось C++ raiSadam's Framework (хоть Enterprise хоть любое другое Edition) — никаких претензий бы не было, но и название сразу перестаёт быть таким громким.
Никаких "своих" фреймворков я и не предлагаю. Я говорю о том, что текущий "открытый" стандарт языка c++ не описывает некоторые сущности, например, логгер или application, а хотелось бы. А в статье собраны реализации того, что хотелось бы в c++ee.
или application
что такое «application» и зачем оно нужно?
Стандарт языка и не должен описывать никакие высокоуровневые сущности, он должен описывать синтаксис и некоторые базовые элементы алгоритмов (которые либо тривиальны и безальтернативны, либо слишком платформенно-зависимы, но при этом всем гарантированно нужны) в виде стандартной библиотеки.
То что хотите вы — это не язык, а фреймворк, и не надо выдавать это под вводящими в заблуждение названиями.
С джавой сравнивать не надо, она не только язык и никогда "только языком" не была, а была весьма обособленной средой для запуска софта.
Тогда JavaEE — это фреймворк?
Несмотря на то, что Java — это коммерческий бренд, и владельцы его могут под ним выпускать что им вздумается, они всё же поступили разумно и в официальной расшифровке "JavaEE" всё указали: Java Platform Enterprise Edition. То есть это платформа. Что-то похожее на фреймворк, да.
Для нативно выполняемых программ платформой является операционная система, в которой обычно имеется пакетный менеджер для установки всего того что вы описали в статье. И такая, с одной стороны, глобальность, а с другой, такое разделение труда (кто-то придумал язык, а кто-то ОС, и работают они независимо) — это плюс нативного софта, а не минус.
Мне кажется Энтерпрайз подразумевает ещё какие-то гарантии и поддержку, что немаловажно для бизнеса.
Чёрта с два вы этот логгер специфицируете как-то так, чтобы всем подошло, уж не говоря о его реализации.
Я соглашусь, т.к. такая же история со стандартными контейнерами. Внезапно выясняется, что каждый, кто серьезно программирует на С++, делает свою реализацию....
Что неужели до сих пор так? Я тоже делал свою реализацию, только лет 10 назад.
C++11 строки появились в libstdc++ в 2007м году, когда ещё ни о какой мув семантике никто и не мечтал — просто их нельзя было сделать стандартом до GCC 5 ибо совместимость же!
А если атомарно — то тут же выясняете, что скопировать сотню байт быстрее, чеим дёрнуть атомарно счётчик один раз
Ну вы неправильно сравниваете. Всё-таки скопировать какую-нибудь строчку это не только «скопировать сотню байт», а еще и сделать аллокацию/деаллокацию. Которые в свою очередь тоже используют разделенное между потоками состояние. А если у нас какой-нибудь старый добрый и повсеместно используемый «вектор строк», то получается что даже на нескольких элементах атомарно дернуть счетчик во много раз быстрее. Без мув семантики у копирования/COW альтернативы только велосипедные — писать кастомные swap функции, жонглировать указателями и т.д.
Всё-таки скопировать какую-нибудь строчку это не только «скопировать сотню байт», а еще и сделать аллокацию/деаллокацию.Не обязательно. Есть short-string optimization.
Которые в свою очередь тоже используют разделенное между потоками состояние.И это тоже не обязательно — tcmalloc (и другие современные) держит про запас немного per-thread буферов… опять-таки, чтобы с atomic'ами не связываться.
Без мув семантики у копирования/COW альтернативы только велосипедные — писать кастомные swap функции, жонглировать указателями и т.д.Ну вот Google померил — и при переходе с GCC 2.95 на GCC 4.2 сделал
#define __gnu_cxx::__versa_string string
Главное - не использовать аргументы типа string где достаточно const string&
А после перехода на C++11 - там уже, в основном, от std::string_view экономия.Не обязательно. Есть short-string optimization.
которая очевидно работает для маленьких строк )
И это тоже не обязательно — tcmalloc (и другие современные) держит про запас немного per-thread буферов… опять-таки, чтобы с atomic'ами не связываться.
«немного»
А после перехода на C++11 — там уже, в основном, от std::string_view экономия.
с++17 то?
Интересно, почему же таких спецификаций и/или решений нет?
Наверное, потому, что писать системы упирающиеся в i/o в 99% случаев на C++ — избыточно и дорого, притом — без какого либо видимого профита(и это если не поднимать тему стрельбы по ногам). Если где-то таки есть ботлнек в памяти или процессоре — то гораздо проще подключить через jni подобный интерфейс точечное решение.
Обзор хороший, но enterprise edition нам, надеюсь, и не светит в общепринятом смысле в каком-то обозримом будующем. Ну разве что железо совсем перестанет развиваться и повышение его утилизации на n% станет выгодно не только гуяндобукам относительно трат на разработку.
Спецификаций действительно нет, а вот решений есть, особенно востребовано это в системах с высоким уровнем защиты и сертификации, т.е. там, где можно только компилировать и нельзя интерпретировать, и нельзя виртуальных машин. Я как то уже отписываться о СЭД Министерства Обороны, так вот там все на c++ и это очень даже Enterprise, теперь, я работаю на антивирусную компанию, и тут тоже c++, который дополнен своим Enterprise Edition. Т.е. и в СЭД и в антивирусе есть разная реализация одних и тех же сущностей, естественно выборка моя не ограничивалась двумя компаниями, их было больше, и общая картина такова, что все мы делаем одно и тоже, только разными способами.
Вам виднее — а я всегда думал, что виртуальные машины "безопаснее". Как минимум всякая обфускация и защита кода зачастую делается с их помощью, но с этой стороной вопроса мне пересекаться практически не довелось.
общая картина такова, что все мы делаем одно и тоже, только разными способами
Вот тут — можно спорить. То, что я видел на плюсах было обычно либо middleware либо разруливанием узкого места. Видел только два решения где был "enterprise" и развесистая логика на плюсах. Система АРМ для автоматизации и учёта инспекций из нулевых(почему там выбрали плюсы и desktop формат — для меня загадка, после 10+ лет развития, за несколько месяцев её переписали на .Net, и в течении года запустили в прод, сократив косты на саппорт в разы, если не на порядок и получили почти бесплатно ещё и web морду) и толстый шлюз с бизнес логикой(там плюсы выбрали в силу немасштабируемости решения горизонтально, т.е. в силу нефункциональных требований, переплевались(все кроме плюсовиков :)), побенчмаркали и всё равно сначала наделали js/java/python адапторов для логики, а потом, насколько я знаю — переписали на java и оставили только пару нативных библиотек с циклами обработки сообщений и парсерами).
Действительно, многие так поступают, перепысывая с плюсов на что-то ещё, с более богатым рантаймом, но это не всегда приемлемо, яркий тому пример — это любое ПО, подвергающееся сертификации, что в России, что в Европе, его нельзя писать не на компилируемых языках, если есть хоть намёк на гриф информации, так вот в этом случае от плюсов не уйти просто. Может пример узковатый получился, но показательный, есть и другие примеры из медицины, например,…
А я как-то совсем не против клуба C++ Enterprise, т.е. людей создающих на С++ решения для Enterprise.
Тележку бы завести под эту тему.
@cppee, коллеги, присоединяйтесь к каналу в телеграмм.
Для указанной архитектуры язык программирования вообще не имеет значения.
Среда разработки и платформа под которую вы пишете, тоже.
Решать придется только одну крупную проблему, и множество мелких.
Крупная проблема — это собрать огромное количество связанных друг с другом частей в единый комплекс.
Мелкая проблема — это написать эти мелкие части (плагины).
Вы же практически все свое внимание сосредоточили на второй проблеме.
Собственно и преподов не видел и однокашников.
C++ Enterprise Edition. Возможно ли?