cpp-peglib 1.10.0 и 1.10.1

Кстати, широко известная в узких кругах cpp-httplib, от этого же автора:

cpp-httplib is an HTTP/HTTPS library for C++. Just copy a single header file, httplib.h, and you’re ready to go.

а PE это pytohon expressions?
в вики просто написано РВ-грамматика, тут непонятно что.

Кстати, широко известная в узких кругах cpp-httplib

Under the hood, it uses blocking I/O with a thread pool. It’s not built for handling massive numbers of simultaneous connections.

Для сколь-нибудь серьезной нагрузки не годится. Вот если бы кто-то вырезал кусок nginx, в части парсинга HTTP и HTTP/2 и работой с соединениями, чтоб можно было юзать со своей логикой… Nginx все таки использует асинхронную, неблокирующую, событийно-ориентированную модель обработки запросов.

ну так сделай сплит, иишкой замаскируй. и скажи что «это палантир/клод/копилот»(с)

Для сколь-нибудь серьезной нагрузки не годится.

В куче проектов используется вместо curl. В Zeal, например.

Кстати, широко известная в узких кругах cpp-httplib

Интересно, её в эмбед можно засунуть? Чтобы с LwIP работала.

Интересно, её в эмбед можно засунуть?

Понятия не имею. :)

Так там же есть своё: https://www.nongnu.org/lwip/2_1_x/group__httpc.html

Да, есть. Но для проекта на плюсах удобнее было бы плюсовую же либу для http сервера. Саму-то LwIP вряд ли заменю, а сервер - почему бы и нет?

А смысл? Оно ж всё дубовое. Неудобно?

Ну фиг знает. Когда вижу в списке параметров функции (void *connection) - сразу хочется выкинуть либу.

ЗЫ. Посмотрел cpp-httplib - тяжеловата для эмбеда. Исключения, std::string, всякие мультимапы/хеши и прочее. Жаль.

Это где такое? Ты имел в виду void *callback_arg? Так это сишные реалии, ничего с этим не сделаешь :/

Boost asio ?

а PE это pytohon expressions?

Parsing Expression Grammar же.

Это в сервере. Я понимаю, что это сишные реалии, но всё равно не нравится:)

Не надо никакие куски вырезать... Напиши сам если нужно. Хотя http/2 весьма неприятный протокол, но реализовать его вполне можно своими силами. И это явно лучше чем копипастить чужие куски кода без понимания.

А что именно тебе тут не правится? То что typedef не сделали вместо void-а?

Да. Никакого контроля типов, никакой подсказки, что там должно быть. И часто бывает несколько уровней вложенности этих void*. Типа, сюда вот надо передать структуру session*, в ней есть void *connection, а у connection есть void *user_data. Но иногда вместо connection может храниться что-то другое, и тогда логика работы меняется. Я не говорю, что везде так, но бывает.

Может быть, Вы знаете библиотеку http-client для C++, в которой транспорт и протокол были бы явно выделенными сущностями: транспорт (например, что-то поверх libevent или аналогов) отвечал за доставку в обоих направлениях и прочие коннекты/дисконнекты, а а протокольная часть отвечала бы за разбор и формирование этих данных, работая поверх представленного транспорта?

Обычно все http библиотеки для C++ упирают на простоту использования: «пихайте свои запросы вот в эту дырку и ждите ответа». Однако, такая схема плохо подходит для случаев одновременной обработки десятков тысяч одновременных соединений и десятков Mbs трафика в многопротокольном сервисе.

А в чем проблема написать самому «асинхронную, неблокирующую, событийно-ориентированную модель обработки запросов» ?

У меня есть серверная часть. Клиентская делается тривиально (см ws client там рядом) https://github.com/resetius/coroio/blob/master/coroio/http/httpd.hpp#L53

Неужели ничего подходящего не нашлось на:

• https://github.com/fffaraz/awesome-cpp
• https://github.com/p-ranav/awesome-hpp

:)

На первый взгляд подходит https://github.com/chronoxor/CppServer:

Ultra fast and low latency asynchronous socket server & client C++ library with support TCP, SSL, UDP, HTTP, HTTPS, WebSocket protocols and 10K connections problem solution.

Has integration with high-level message protocol based on Fast Binary Encoding

Возможно, что её автор и на ЛОРе есть. :)

Спасибо, посмотрю!

Не надо никакие куски вырезать… Напиши сам если нужно.

Дык написал уже. HTTP 1.(0/1) очень прост для парсинга. Но я бы с радостью взял уже готовую реализацию. Заглянул в исходники nginx и был приятно удивлен как там классно реализованы парсеры и работа с событиями/сокетами.

Намного полезней будет научиться по этим исходникам делать аналогичное, а не тупо их копипастить.

В отличие от таких проектов, как PEGTL, Lexy и многих других, cpp-peglib позволяет задать выражение PEG и во время выполнения.

Есть ли в этом какой-то практический смысл кроме как уменьшение объема потребляемой С++ным компилятором памяти и сокращения времени работы C++ компилятора?

Есть ли в этом какой-то практический смысл

Он же на скриншоте.

Он же на скриншоте.

На скриншоте абстрактный конь в сферическом вакууме – какая из этого практическая польза – лично мне не ведомо и если кто-то пояснит, то буду признателен.

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

duration = value ( multiplicator )
value = NUMBER
multiplicator = 'd' | 'h' | 'm' | 's' | 'ms' | 'us'

Соответственно из знаний структуры мы затем строим работу с результатом парсинга, т.е. берем число и, если есть, конкретный мультипликатор и строим итоговое значение (скажем, в виде std::chrono::duration).

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

Как раз вожусь с Lexy, сабж выглядит гораздо дубовее. Типы стираются, всюду any, динамика, императивщина. Динамическая грамматика при этом - странная фича.

Но хорошо что PEG. Кажется, пора уже вытеснять Хомского.

HTTP 1.(0/1) очень прост для парсинга

Вот это (github.com) - «очень прост»? Завидую.

Мне хватило открыть спеку http 1.1, чтобы передумать писать парсер и взять готовый (из того же nginx, в виде http-parser). Иначе до самой задачи я бы дошел еще очень не скоро, а баги собирал бы бесконечно.