Парсер математических выражений c#

Packrat Parsers

Допустим, мы хотим распарсить последовательность единичек:

Парсинг начинается с того, что мы вызываем парсинг , который снова …

Попытка распарсить единички приведёт к переполнению стека.

В данном случае можно изменить описание так, чтобы каждый раз «поглощалось» что-нибудь. Например:

Но не всегда грамматику легко переписать. Выражния типа должны распознаваться именно как , вариант не подойдёт. С делением будет аналогичная проблема. Как это сделать без усложнения грамматики?

Нас спасут packrat — парсеры. Их идея заключается в том, что парсер может хранить «для себя» некоторую информацию о вызовах. Например, чтобы сохранять результат работы и не парсить одно и то же дважды… или чтобы корректно работать в случаях с рекурсией.

в трейте PackratParsers содержится неявное преобразование строчек и прочего в парсеры «нужного» типа.

PackratParser лучше создавать только один раз и хранить в переменной. Кроме того, если парсер использует , а использует , стоит использовать ленивую инициализацию.

Думаю, теперь понятно, как можно легко и непринуждённо распарсить 3-2-1 как (3-2)-1.

Возможно, у вас возникает вопрос: где парсер хранит информацию? Если её хранить прямо внутри PackratParser, то вызов парсера для другого ввода может дать некорректные результаты. Так вот, необходимая информация хранится вместе с «входными» данными парсера. Можно заглянуть в код библиотеки и убедиться в этом:

Поэтому парсер принимает на вход не строку, а

Что самое крутое — использование packrat парсеров ни к чему не обязывает, их можно комбинировать с обычными парсерами и наоборот.

await this.request(method, url[, queryParams][, opts])#

awaitthis.request(method, url, queryParams, opts)

Скопировать

Получение HTTP ответа по запросу, в качестве аргументов указывается:

• — метода запроса (GET, POST…)
• — ссылка для запроса
• — хэш с get параметрами или хэш с телом post-запроса
• — хэш с опциями запроса

Если используется метод POST, то тело запроса можно передать двумя способами:

просто перечислив названия переменных и их значения в queryParams. Например:

{

key set.query,

id1234,

type ‘text’

}

Скопировать

через переменную body в opts. Например:

body ‘key=’ + set.query + ‘&id=1234&type=text’

Скопировать

— массив условий для проверки получаемого контента, если проверка не проходит, то запрос будет повторен с другим прокси.

Возможности:

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

Для успешного запроса должны пройти все указанные в массиве проверки

let response =awaitthis.request(‘GET’, set.query,{},{

check_content

<\/html>|<\/body>,

‘XXXX’,

‘</html>’,

(data, hdr)=>{

return hdr.Status==200&& data.length>100;

}

});

Скопировать

— автоматическое определение кодировки и преобразование в utf8

Возможные значения:

• — на основе заголовков, тегов meta и по содержимому страници (оптимальный рекомендуемый вариант)
• — указывает что документ в кодировке utf8
• — любая другая кодировка

— хэш с заголовками, название заголовка задается в нижнем регистре, можно указать в т.ч. cookie
Пример:

headers{

accept’image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8′,

‘accept-encoding»gzip, deflate, br’,

cookie’a=321; b=test’,

‘user-agent»Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36’

}

Скопировать

— позволяет переопределить порядок сортировки заголовков

— максимальное число переходов по редиректам, по умолчанию 7, используйте 0 для отключения перехода по редиректам

— число попыток выполнения запроса, по умолчанию берется из настроек парсера

— перечень кодов HTTP ответов, которые парсер будет считать удачными, по умолчанию берется из настроек парсера. Если указать то все ответы будут считаться удачными.
Пример:

parsecodes{

2001,

4031,

5001

}

Скопировать

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

— определяет использовать ли компрессию (gzip/deflate/br), по умолчанию включено (1), для выключения нужно задать значение

— максимальный размер ответа в байтах, по умолчанию берется из настроек парсера

— хэш с куками. Пример хэша:

«cookie_jar»{

«version»1,

«.google.com»{

«/»{

«login»{

«value»»true»

},

«lang»{

«value»»ru-RU»

}

}

},

«.test.google.com»{

«/»{

«id»{

«value»155643

}

}

}

}

Скопировать

— указывает на номер текущей попытки, при использовании этого параметра встроенный обработчик попыток для данного запроса игнорируется

— автоматическая эмуляция заголовков браузера (1 — включено, 0 — выключено)

— переопределяет использование прокси для отдельного запроса внутри JS парсера поверх глобального параметра Use proxy (1 — включено, 0 — выключено)

— отключает добавление Extra query string к урлу запроса (1 — включено, 0 — отключено)

— позволяет скачать файл напрямую на диск, минуя запись в память. Вместо file указывается имя и путь под каким сохранить файл. При использовании этой опции игнорируется все, что связано с data (проверка контента в check_content, response.data будет пустой и т.д.).

— определяет передавать (1) или нет () в ответе data/pages[], может использоваться для оптимизации

— определяет возвращать data как строку String () или как объект Buffer (1), по умолчанию возвращается строка String

— автоматический обход JavaScript защиты CloudFlare используя браузер Chrome (1 — включено, 0 — выключено)

— позволяет переходить по редиректам, объявленным через HTML мета тег:

<metahttp-equiv=»refresh»content=»time; url=…»/>

Скопировать

– позволяет передавать для https соединений
​

UDPipe 2.0

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

Как работает UDPipe 2.0

• LeftArc — применим, если второй элемент стека не root. Сохраняет зависимость между токеном на верхушке стека и вторым токеном, а также выкидывает второй из стека.
• RightArc — то же самое, но зависимость строится в другую сторону, и отбрасывается верхушка.
• Shift — переносит очередное слово из буфера в стек.

источникссылке

Проблемы UDPipe

«Глокая куздра штеко будланула бокра и курдячит бокрёнка».Tagging from plain text (CoNLL17 F1 score)

• gold forms: 301639,
• upostag: 98.15%,
• xpostag: 99.89%,
• feats: 93.97%,
• alltags: 93.44%,
• lemmas: 96.68%

разработка яндексаинтересныхстатей

• «нет директора» — родительный падеж единственного числа
• «я вижу директора» — т.е. винительный падеж единственного числа
• «это какие-то директора» — именительный падеж множественного числа (ударения-то у нас на письме нет)

RNNMorphMorphoRuEval-2017russian_tagsetspackage

Приоритет и ассоциативность операций

Чтобы решить обе проблемы, нам нужно дать парсеру информацию о приоритетах операций.

Делать мы это будем через таблицы . Эти таблицы можно сделать глобальными и переиспользовать между парсерами, но нам проще разместить их прямо в конструкторе парсера, для локальности кода:

Метод теперь будет принимать аргумент :

С помощью нового аргумента парсер знает, когда продолжать, а когда остановиться, что позволяет правильно связать итоговое AST.

Каждый парслет теперь должен передать свой (приоритет) при вызове :

связывает выражения как лево-ассоциативные. Чтобы разобрать право-ассоциативные выражения, нужно вычесть 1 из приоритета операции:

В начале статьи мы уточнили, что у нас будет право-ассоциативный, поэтому обрабатываться побитовый сдвиг будет с помощью .

Парсите HTML теги

Если случилось чудо и у сайта нет ни официального API, ни вкусных XHR запросов, ни жирного JSON внизу HTML, если рендеринг браузерами вам тоже не помог, то остается последний, самый нудный и неблагодарный метод. Да, это взять и начать парсить HTML разметку страницы. То есть, например, из достать ссылку. Это можно делать как простыми регулярными выражениями, так и через более умные инструменты (в питоне это BeautifulSoup4 и Scrapy) и фильтры (XPath, CSS-selectors).

Мой единственный совет: постараться минимизировать число фильтров и условий, чтобы меньше переобучаться на текущей структуре HTML страницы, которая может измениться в следующем A/B тесте.

Синтаксический анализатор

• Легкость расширения при изменении грамматики
• Возможность описывать подробные сообщения об ошибках
• Возможность заглядывать вперед на неограниченное количество позиций
• Автоматическое отслеживание положения в исходном коде
• Лаконичность, близость к исходной грамматике

• Описание — один конкретный узел:
• Повторение — один конкретный узел повторяется многократно, возможно с разделителем:
• Альтернатива — выбор из нескольких узлов

— Как это, просто вызываются по порядку? А как же опережающие проверки? Например, так:

1. Первой вызывается альтернатива .
2. Идентификатор успешно совпадает.
3. Дальше идет точка, а ожидается знак «равно». Однако с идентификатора могут начинаться и другие правила, поэтому ошибка не выбрасывается.
4. Правило assign откатывает состояние назад и пробует дальше.
5. Вызывается альтернатива .
6. Идентификатор и точка успешно совпадают. В грамматике нет других правил, которые начинаются с идентификатора и точки, поэтому дальнейшие ошибки не имеет смысл пытаться обработать откатыванием состояния.
7. Число не является идентификатором, поэтому выкидывается ошибка.

• Откат состояния — очень дешевая операция
• Легко управлять тем, до куда можно откатываться
• Легко отображать детальные сообщения об ошибках
• Не требуются никакие внешние библиотеки
• Небольшой объем генерируемого кода

• Реализация парсера вручную занимает время
• Сложность написания и оптимальность работы зависят от качества грамматики
• Леворекурсивные грамматики следует разруливать самостоятельно

HtmlAgilityPack#

This is an agile HTML parser that builds a read/write DOM and supports plain XPATH or XSLT (you actually don’t HAVE to understand XPATH nor XSLT to use it, don’t worry…). It is a .NET code library that allows you to parse «out of the web» HTML files. The parser is very tolerant of «real world» malformed HTML. The object model is very similar to what System.Xml proposes, but for HTML documents (or streams).

In terms of features and quality it is quite lacking, at least compared to AngleSharp. Support for CSS selector, necessary for modern HTML parsing, and support for .NET standard, necessary for modern C# projects, are on the roadmap. On the same README document there is also planned a cleanup of the code (https://github.com/zzzprojects/html-agility-pack).

So, in my opinion, HtmlAgilityPack is not such good option to start project with, but it’s ok to continue working with this library and receive updates from the contribution team.

The usage of the library is quite straightforward, but let’s check the sample:

// @nuget: HtmlAgilityPack

using System;
using HtmlAgilityPack;
using System.Collections.Generic;

public class Program
{
public static void Main()
{
// Load
var doc = new HtmlDocument();
doc.LoadHtml(@»<html><body><div id=’foo’>I love ScrapingAnt <3</div></body></html>»);
var div = doc.GetElementbyId(«foo»);

// Show info
System.Console.WriteLine(div.OuterHtml);

// Show info
FiddleHelper.WriteTable(new List<string> () {div.OuterHtml });

// Show info
FiddleHelper.WriteTable(new List<HtmlAgilityPack.HtmlNode> () { div});
}
}

Copy

Also, check out the online in-browser examples from the official website: https://html-agility-pack.net/online-examples

Десктопные и облачные парсеры

Облачные парсеры

Основное преимущество облачных парсеров — не нужно ничего скачивать и устанавливать на компьютер. Вся работа производится «в облаке», а вы только скачиваете результаты работы алгоритмов. У таких парсеров может быть веб-интерфейс и/или API (полезно, если вы хотите автоматизировать парсинг данных и делать его регулярно).

Например, вот англоязычные облачные парсеры:

• Import.io,
• Mozenda (доступна также десктопная версия парсера),
• Octoparce,
• ParseHub.

Из русскоязычных облачных парсеров можно привести такие:

• Xmldatafeed,
• Диггернаут,
• Catalogloader.

Любой из сервисов, приведенных выше, можно протестировать в бесплатной версии. Правда, этого достаточно только для того, чтобы оценить базовые возможности и познакомиться с функционалом. В бесплатной версии есть ограничения: либо по объему парсинга данных, либо по времени пользования сервисом.

Десктопные парсеры

Большинство десктопных парсеров разработаны под Windows — на macOS их необходимо запускать с виртуальных машин. Также некоторые парсеры имеют портативные версии — можно запускать с флешки или внешнего накопителя.

Популярные десктопные парсеры:

• ParserOK,
• Datacol,
• Screaming Frog, ComparseR, Netpeak Spider — об этих инструментах чуть позже поговорим подробнее.

Чек-лист по выбору парсера

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

1. Четко определите, для каких задач вам нужен парсер: анализ SEO конкурентов или мониторинг цен, сбор данных для наполнения каталога, съем позиций и т.д.
2. Определите, какой объем данных и в каком виде нужно получать.
3. Определите, как часто вам нужно собирать данные: единоразово или с определенной периодичностью (раз в день/неделю/месяц).
4. Выберите несколько инструментов, которые подходят для решения ваших задач. Попробуйте демо-версии. Узнайте, предоставляется ли техническая поддержка (желательно даже протестировать ее — задать парочку вопросов и посмотреть, как быстро вы получите ответ и насколько он будет исчерпывающим).
5. Выберите наиболее подходящий сервис по соотношению цена/качество.

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

Пример задачи парсинга

Рассмотрим практический пример задачи извлечения данных. Допустим, мы хотим написать свою конфигурацию для учета инвестиций в акции и другие инструменты. Но вся необходимая информация хранится на разных сайтах или доступна только через REST API. Придется парсить разные источники, чтобы получать данные об инструментах, новостях, показателях компаний и т.д. Преимущество реализации на 1С в том, что мы можем написать несколько парсеров для разных источников и представить сводку в удобном виде, используя преимущества быстрой разработки на 1С – базу данных, конструктор форм и все другие средства.

Возьмем за основу и начальную точку сайт «Тинькоф-инвестиции» и проанализируем структуру страницы с информацией о акциях – на примере Apple https://www.tinkoff.ru/invest/stocks/AAPL/. Выделим блоки с нужной информацией и их CSS-селекторы:

Здесь заметно, что имена классов имеют суффикс со случайным набором символов, но это мы легко обойдем.

Проверить корректность отбора можно в консоле разработчика любого браузера (кнопка F12), используя функции document.getElementsByClassName(), document.getElementById(), document.getElementsByTagName() или отбор через jQuery, который все еще часто применяется на многих сайтах: если вызов функции «$» не выдаст ошибки, можно проверять отборы по селекторам в виде $(“.classname”), $(“#element-id”) и т.д.

Создадим код для получения текста страницы:

Теперь подготовим объект документа для анализа и получения данных:

Дальше сформируем фильтр для передачи в функцию поиска по документу. Фильтр это конфигурация отбора в виде JSON-строки, и у нее есть два корневых элемента – type и value. Есть несколько типов и для каждого — несколько допустимых значений, полное описание вариантов есть в синтаксис-помощнике в разделе «Описание структуры JSON-конфигурации для отбора».

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

В нашем случае – реализуем функцию для формирования фильтра поиска по тегу и классу элемента, для этого нужно выбрать тип «пересечение условий» («intersection») и добавить  значение «value» как массив из трех условий – на равенство тега, наличие атрибута «class» и поиск по шаблону для значения атрибута:

Здесь в зависимости от флага «ТочноеСоответствие» используется два варианта отбора – точное равенство или проверка по регулярному выражению. Это позволяет задавать сложные шаблоны поиска селекторов. В нашем случае при неточном соответствии в переменной ИмяКласс помещаем переданное значение и добавляем символы «.+», что означает «1 или более любых символов» после указанного значения.

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

Здесь мы сочетали получение узла по селектору и получение дочерних узлов из DOM-структуры вместо нескольких выборок по селектору. В простых случаях это может быть удобнее.

Шаг 3. Пример из реального мира

Для демонстрации библиотеки в действии мы напишем скрипт для скрепинга содержимого сайта net.tutsplus.com и формирования списка заголовков и описания статей, представленных на сайте….только в качестве примера. Скрепинг относится к области трюков в веб, и не должен использоваться без разрешения владельца ресурса.

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

Так же объявим глобальный массив, чтобы сделать проще сбор все информации о статьях в одном месте. Прежде чем начинать парсинг взглянем, как описывается статья на сайте Nettuts+.

Так представлен основой формат поста на сайте, включая комментарии исходного кода. Почему важны комментарии? Они подсчитываются парсером как узлы.

Какой бывает парсинг в соцсетях?

Парсинг соцсетей – это быстрый и простой способ извлечь ценную информацию о ЦА из триллионов байт данных. Парсинг – не самое точное название. На самом деле это этап скрейпинга – автоматизированного сбора информации, когда из собранных данных извлекаются нужные сведения. Но не будем отвлекаться, так как в русскоязычных источниках парсинг – это синоним скрейпинга.

Информацию можно собирать внутри сервиса парсинга и вручную выгружать готовые базы либо включить в процесс API.

API (интерфейс программирования приложений) – это программное обеспечение (ПО), которое помогает обмениваться данными с другим ПО, изначально не предназначенным для совместной работы.

Как это связано с парсингом? Подключите API и сможете автоматизировать процесс:

• Собирать данные в режиме реального времени. Это особенно полезно для платформы, где тенденции могут поменяться в считанные минуты.
• Настроить автоматическую воронку сбора данных. Например, воронки помогут сравнить конверсию в целевое действие для разного контента или узнать, что и какой части аудитории зашло на ура.
• Переносить инфу сразу в вашу базу данных или аналитическое ПО без вмешательства человека.

API, подключенный к инструменту парсинга, поможет собирать и передавать информацию напрямую другому ПО, например, вашей базе данных. А еще поможет установить автоматические запросы на очистку через заданные интервалы. Парсинг через API не остановится, даже если вас нет на месте.

Серверный режим работы парсера

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

Задача разбора по одному предложению может быть решена либо использованием
библиотеки PyParser из кода на питоне,
либо запуском REST-сервиса.

Запуск в режиме RESR-сервиса (см. файл http.cmd в дистрибутиве):

Parser_RestHttpService.exe -tagger 0 -parser -1 -lemmatizer 0 -d dictionary.xml -url 127.0.0.1 -port 10973

Опция -url 127.0.0.1 задает сетевой интерфейс, на котором будет доступен сервис. Чтобы
сервис был доступен из любых внешних сетей, нужно указать адрес 0.0.0.0, или подставить
адрес конкретного сетевого интерфейса.

-port 10973 адрес порта, через который веб-сервис будет работать по http.

В дистрибутиве проекта есть пример вызова сервиса парсинга на Питоне.

Большие ограничения

Данный материал не подойдет, если Вы решаете следующие задачи:

• Получение и обработка данных на сервере регламентным заданием или любым другим.
• Обработка очень большого массива данных.
• Пытаетесь парсингом заменить работу через API из-за его отсутствия или недоступности.
• Вам нужен надежный способ получения данных.

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

Парсинг веб-ресурсов почти всегда «зло» как по отношению к владельцу ресурса, так и в части сопровождения таких решений. Ведь стоит разметке поменяться и алгоритмы извлечения данных нужно снова менять.

Однако, иногда выхода нет. Да и использование предлагаемого подхода можно считать этичным в каком-то плане, потому что создаем всего лишь помощника работы с браузером и автоматизируем действия пользователя на веб-странице. Хотя это вопрос «холиварный».

Тестируем лексер

Для того, что бы точно быть уверенным в иммутабельности вывода лексера и дать гарантию следующим этапам обработки, следует закрепить вывод токенов. Этап токенизации берет на себя лексер, так же именно в этом этапе выгодно добавлять препроцессирование, так что бы на выходе можно было получить сразу готовый поток токенов. Для таких языков как С++ лексер просто необходимо запускать отдельно от парсера, что бы получать корректный вывод — иначе вы все макросы не раскроете. Соответственно для него нужно в начале все файлы прогнать через лексер, а только потом парсер.

Одним из вариантов является сохранение как есть потока результата работы лексера — токенов в файл, вот только бинарные файлы люди пока читать не научились, поэтому предлагаю использовать json, это поможет не только видеть изменения через дельты с минимальными шумами, но так же позволит автоматизировать поиск разницы.

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

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

Имея на руках такой дамп представления файла, довольно легко написать юнит-тест:

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

Выделив код в библиотеку можно добавить тестирование лексера, всего лишь написав конфигурацию для теста:

Данный тест создаст из ресурсной папки /test/java/unit коллекцию тестовых наборов данных (suite), а уже junit создаст все необходимые тесты и передаст каждый из них в качестве параметра нашему методу testLexer, вызываем затем родительский метод и вуаля — наша грамматика тестируется, и так для любого языка. Генерируем дампы и запускаем тест!

Парсеры поисковых систем#

await this.sessionManager.*#

Для использования сессий в JS парсере сначала нужно инициализировать Менеджер сессий. Делается это с помощью функции

asyncinit(){

awaitthis.sessionManager.init({

});

}

Скопировать

В можно использовать следующие параметры:

• — необязательный параметр, позволяет переопределить имя парсера, которому принадлежат сессии, по-умолчанию равно имени парсера, в котором происходит инициализация
• — необязательный параметр, возможность менять прокси, по-умолчанию равно 1
• — необязательный параметр, указывает искать сессии среди всех сохраненных для этого парсера (если значение не задано), или же только для конкретного домена (необходимо указывать домен с точкой спереди, например )

Для работы с сессиями существует несколько функций:

— получает новую сессию, необходимо вызывать перед осуществлением запроса

— очистка куков и получение новой сессии. Необходимо вызывать, если с текущей сессией запрос не был удачным.

— сохранение удачной сессии либо сохранение произвольных данных в сессии

Пример сохранения произвольных данных и дальнейшего их получения:

asyncinit(){

awaitthis.sessionManager.init({

});

}

asyncparse(set, results){

this.logger.put(«Start scraping query: «+set.query);

let ua =’Mozilla/5.0 (Windows NT 10.0; Win64; x64)’;

let referer =set.query;

let data =’Some data’;

awaitthis.sessionManager.save({ua, referer, data});

let session =awaitthis.sessionManager.get();

this.logger.put(«Session: «+JSON.stringify(session));

results.SKIP=1;

return results;

}

Скопировать

Мы не упоролись плюсовыми шаблонами

Первый ответ, наименее очевидный, состоит в том, что мы хотим рассказывать не только о том, что RESTinio делает, но и как он это делает. В частности, о технических решениях, применяемых в реализации RESTinio.

Думаю, что эта информация несколько повышает степень доверия к нашей разработке. Ведь одно дело, когда человек заглядывает в исходники RESTinio, видит там шаблонную магию и думает, что это просто потому, что авторы упоролись шаблонами и пытаются проверить C++ные компиляторы на прочность. Совсем другое дело, когда принятые нами решения объяснены и аргументированы.

Сам по себе easy_parser появился в RESTinio не просто так, а как результат попытки добавить в RESTinio средства работы с HTTP-заголовками.

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

Использование парсера на базе грамматик выглядело как наиболее подходящее решение, но вот вариант затащить в проект какой-то генератор парсеров (вроде bison, coco/r, ragel и пр.) рассматривался как нежелательный. RESTinio является header-only библиотекой (хоть и требует линковки к libhttp-parser). А использовать для разработки кросс-платформенной header-only библиотеки внешние генераторы кода выглядит так себе идеей. Кроме того, смущал вот какой момент: допустим, мы сгенерируем код для разбора каких-то штатных заголовков и этот код попадет в состав RESTinio, но что делать пользователю, которому захочется разобрать какой-нибудь нестандартный заголовок (или стандартный, но поддержки которого еще нет в RESTinio)? Писать разбор вручную или осваивать ragel или coco/r? Ну так себе выбор, как по мне.

Cтатья продемонстрировала как выглядит добавление поддержки HTTP-заголовка в RESTinio с помощью easy_parser-а. Это может показаться чрезмерным усложнением.

Но…

На практике, после освоения easy_parser, написать показанный выше код не сложно. Это занимает совсем немного времени. Гораздо больше уходит на то, чтобы a) вкурить соответствующую часть RFC, b) понять, во что именно должно трансформироваться разобранное значение, какие структуры потребуются для хранения результата разбора, c) покрыть написанный парсер тестами и d) задокументировать это все. Так что, бывает, что общая работа по реализации поддержки какого-то не самого простого заголовка занимает 4-6 часов, из которых написание связанного с easy_parser-ом кода — это всего 15-20 минут.

Так что, хоть у easy_parser-а в RESTinio есть свои особенность и недостатки, все-таки его создание и использование в RESTinio пока что выглядит оправданным.

Похожие записи:

Лаборатории «инвитро» в москве Как и где получить кредит на открытие бизнеса Самостоятельное структурное подразделение это 5 сервисов для избавления от ненужных вещей в москве Как живут священники в россии: о зарплате в 200 тысяч и дорогих автомобилях Магнит выкупает сеть дикси