Проблема экосистемы C++

Сишка

Это скорее преимущество, так как не надо ковыряться в чужих шаблонах, когда что-то не работает. Да и объективно это самая стандартная и универсальная библотека, те же WebKit и Chromium ее используют

На кой черт

Вот что это такое: https://github.com/svgpp/svgpp/blob/master/src/samples/sample_gradient.cpp#L2... ?

«Гибкий подход»

Вот что это такое: https://github.com/svgpp/svgpp/blob/master/src/samples/sample_gradient.cpp#L2...

Это явно не «проблема экосистемы C++», а просто один конкретно взятый поехавший на шаблонах крестодевелопер.

tinyxml2 неплох, но он написан на C с классами и использует const char* для строк.

И это замечательно, так как иначе без string_view не получится избавиться от лишних копий данных

Хотя типы пишут что типа быстрее даже xercesc_sax. Вот spdlog тоже много чего пишут про свою мега скорость, а на деле пшик и ноль возможностей конфигурации.

Сказали же хорошую,
а не говно тормозное

Я назвал хорошую. Да, она не идеальна по скорости, а на x86_64 на уровне pubixml.

pugixml

Хороший парсер, не спорю. Можно еще в сторону rapidxml посмотреть.

Ты ж кресты хэйтишь вроде?

Я их клинически не переношу, потому что 99% того, что на них пишут - вырвиглазный темплейтнутый ахтунг. Но на крестах можно также писать вменяемо, на из всего поголовья крестодевелоперов способны дай боже процентов 10.

Твой херес не умеет в in-place парсинг, а значит люто сливает по скорости пуги. А если обязательно нужен сакс/пулл, так как данных сильно много, то лучше взять libxml2 и не париться.

К тому же pugixml - это три файла, и можно использовать как header-only

почему бы не использовать в C++ обычные C-шные либы

Тотальный unsafe.

rapidxml давно не развивается, а pugixml активно развивается, и автор готов дорабатывать под конкретные случаи

https://crates.io/crates/log

Любая незнакомая чужая либа на С или С++ - это просто минное поле, так что unsafe повсюду

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

Вы сорцы stl видели?

А есть ссыль на бенчмарки in_memory/dummy логгеров с разным аффинити и с вкл/выкл режимами логгирования?

Ну или вообще на какие то бенчмарки?

А то я могу тебе так же сказать - log4cpp и boost::log.

потому что 99% того, что на них пишут - вырвиглазный темплейтнутый ахтунг

Нет, таких ахтунгов обычно гонят в зашей из плюсовых контор, и они уходят в более обезъяньи ниши рынка. Но таки да, встретить поделие wannabe Александреску - более чем реально

логгирования

Граммар-наци негодуэ

spdlog же.

Тотальный unsafe.

То, что происходит внутри 3-rd party библиотеки не ваша головная боль. А поверх можно на C++ какие угодно обертки накрутить. Скажем, удобная плюсовая обертка над libcurl делается с полпинка, а удобство затем возрастает на порядок.

и автор готов дорабатывать под конкретные случаи

Это хорошо, но валидацию он даже опциональную добавлять не планирует.

А на кой она нужна в парсере-то?

но всякие тини ходили на несколько порядков позади особенно в случае потока мелких документов

Несколько порядков - это в сотню раз. Очень сомневаюсь, что tinyxml так сильно отстает. Даже бенчи pugixml говорят о том, что tinyxml достаточно шустрый.

А на кой она нужна в парсере-то?

Валидация нужна что бы валидировать то, что подсунет пользователь на вход приложения.

А вы сами с какого раена к нам пожаловали? Уж не с ново-джавоскриптовского?

Вот что это такое: https://github.com/svgpp/svgpp/blob/master/src/samples/sample_gradient.cpp#L2... ?

Выглядит как метапрограммирование на шаблонах на Boost.MPL. Посредством первого экземпляра mpl::set задается множество подлежащих обработке тегов. А посредством второго — множество подлежащих обработке атрибутов. С раскручиванием всего этого дела в compile-time.

Далеко не всем C++никам нужны такие вещи. А вот те, кто использует, рассказывает, что по-другому получается сильно хуже (по целому ряду критериев).

Уж не с ново-джавоскриптовского?

Растолюб же.

Ну вот он взял и почти на порядок слил в своём асинхронном режиме со всякими настройками буффера когда по 700метров памяти ему нужно, проприетарной самопальной реализации которая до кучи память особо не жрёт и в порядке времени записи пишет в отличии от поделки.

Он выдаёт хорошие результаты левее 50% распределения да, но имеет жёсткие вылеты правее 90%, да ещё и не по порядку пишет. Т.е. как trace для бизнесс логики работает так себе даже если давать ему подразгребать очередь. avg получается красивый, но может эта штука на выделенном проце и на сотню us подвесить поток выполнения, притом довольно часто.

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

Во многих случаях можно использовать - но как универсальное решение не годится видимо. Хотя дамми/в память конфиг я поленился для него сделать, тем более это всё равно не жизненный кейс и было из чего выбирать.

С отключенным режимом логгирования тоже слив был, хотя им бы можно было и пренебречь.

Может я конечно просто не умею готовить, но нашёлся заточенный под задачу вариант который готовить не надо.

Валидация нужна что бы валидировать то, что подсунет пользователь на вход приложения.

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

На мой взгляд схема нужна в двух случаях: 1) этот формат предполагается использовать для передачи данных между несвязанными приложениями и 2) если хочется генерировать кож парсеров по схеме

Видел трэд на двух страницах.

И эти люди рассказывают как в C++ всё хорошо?

А при чем все эти пункты к С++?

Мопед не мой, я только доки с отчётом читал. В голове отложилось что xercesc - есть мощь мощная в случае много мелких документов сплошным потоком.

Может я конечно просто не умею готовить, но нашёлся заточенный под задачу вариант который готовить не надо.

А вариант использования трассировщика вместо логирования не рассматриваете? А то есть lttng

Если бы не было никакой мощи, то эта блоатварь давно бы скопытилась

Надо было в кроссплатформу, потом правда всё скатилось в linux-only :)

Была там ещё в выборке какая то либа для телеметрии не соврать бы но название было вида p8 или как то так. Выбрал первое что давало приемлемые результаты для решения задачи, было бы у spdlog распределение по стабильней, пусть и с худшим avg - я бы и его оставил.

Трассировщики типа предложенного никогда не использовал - в чём профит кроме скорости? Можно у события кастомные поля иметь?

Вижу, можно, крутая штука однако.

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

Мне валидация вообще не нужна, т.к. на входе всегда валидный xml. Но я допускаю, что всяким inkscape или svg-парсерам он может быть нужен.

В голове отложилось что xercesc - есть мощь мощная в случае много мелких документов сплошным потоком.

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

Собственная либа для работы с fs.

это - извращение в 99% случаев, остальное ещё куда ни шло.

Не, такой сложный документ схемой не провалидируешь толком, он запросто может быть валидным по схеме и некорреткным относительно стандарта

это - извращение в 99% случаев,

Абстракция над файловой системой вполне разумное решение.

это - извращение в 99% случаев

а что, без с++17 есть адекватные варианты?

Не, такой сложный документ схемой не провалидируешь толком, он запросто может быть валидным по схеме и некорреткным относительно стандарта

Ну значит автор pugixml прав, что не желает вкручивать валидацию.

Да, но ФС и ОС много. Зачем городить велосипеды? Тем более непонятно на каком уровне он делает абстракцию, можно и до уровня драйвера FS дойти.

А что, нельзя взять что-то готовое? Вон boost вроде умел с fs работать, правда мне особо не надо было.

По крайней мере, это отдельная от парсинга xml задача

Да, но ФС и ОС много.

И почему это должно мешать абстракции над ФС?

Зачем городить велосипеды?

Я не могу сказать за автора этой библиотеки, поскольку не видел ее. Возможно в этом был какой-то смысл.

Тем более непонятно на каком уровне он делает абстракцию, можно и до уровня драйвера FS дойти.

Наверное можно посмотреть сорцы или пообщаться с автором, но мне это не нужно.

можно и до уровня драйвера FS дойти

В никсах дальше уровня системных вызовов ты не уйдешь

Уйдешь, по крайней мере на свободных никсах - можно модуль ядра написать.