Разбор QString

[Igors]

... подход (концепция) решения этой задачи ...

А я вот не уверен что концепция так уж хороша (с бустом или без).

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

Код

C++ (Qt)
enum {
 type_String,     // строка, клиент разбирается сам
 type_Quote,     // цитата, известно какая
 type_Number,  // число (см выше в теме)
 type_EOL,       // конец строки
 type_Char,      // символ, клиент разбирается сам
};
 

[Old]

А я вот не уверен что концепция так уж хороша (с бустом или без).

Буст предлагает самое низкоуровневое (универсальное) решение, а вы, например, можете сделать на его основе "среднее" (как вы сейчас предложили). А конечный пользователь (и вы в том числе), на основе "среднего" сможете делать конечные парсеры на любой вкус и кошелек.

type_Quote,     // цитата, известно какая

Что значит известно какая? Это "..." или '...' или `...` или `...' (и такие есть)?
И что она будет означать? Если клиенту нужны токены (...), а на входе: (13123 ")24324" 345345), что будет возвращено - цитата или строка?

[Old]

10.2           // тут хужее, точка может юзаться и по-другому
3.45f          // увы, это возможно
1.2e-5        // и это надо поддерживать
2.3e+10f    // и это

Если точка может быть разделителем токенов, то никак.

[Igors]

Что значит известно какая?

Пример: парсер вернул токен

(a + b)

Это правильно, т.к. клиенту нужно "все что в скобках" + знать что "это в круглых скобках". Однако получив токен клиент вероятно будет пытаться выяснить "а цитата ли это" и "какая". Это явно неэффективно т.к. парсер только что это уже сделал - так пусть он и запишет ее ID чтоб потом не бегать.

Если точка может быть разделителем токенов, то никак.

Ну чего же, пробежаться вперед никто не запрещает

[Old]

Это правильно, т.к. клиенту нужно "все что в скобках" + знать что "это в круглых скобках". Однако получив токен клиент вероятно будет пытаться выяснить "а цитата ли это" и "какая". Это явно неэффективно т.к. парсер только что это уже сделал - так пусть он и запишет ее ID чтоб потом не бегать.

А цитат может быть много: (...) {...} "..." '...' и т.д.
Какой будет ID? А пользователю придется выяснять все равно, что это за цитата.

Ну чего же, пробежаться вперед никто не запрещает

Пробегитесь: 1.4.5.6.12.55.66f.123
Сколько здесь чисел и какие?

[Igors]

А цитат может быть много: (...) {...} "..." '...' и т.д.
Какой будет ID? А пользователю придется выяснять все равно, что это за цитата.

Конечно придется, но куда меньшими затратами

Пробегитесь: 1.4.5.6.12.55.66f.123
Сколько здесь чисел и какие?

Здесь ни одного числа, это один токен - строка, а вот напр так

1.4  5.6.12.55.66f.123

2 токена, number и string.

Edit: виноват, не один и не строка - серия токенов строка + символ (если точка юзается). Но суть та же - клиенту трудно "без контекста" - он будет вынужден привлекать пред/пост историю. Разумно переложить это на базовый парсер.

[m_ax]

А цитат может быть много: (...) {...} "..." '...' и т.д.
Какой будет ID? А пользователю придется выяснять все равно, что это за цитата.

Конечно придется, но куда меньшими затратами

Меньшими чем что?
Ну хорошо, предположим, понадобилась вам такая функциональность (можно понять).. И что, будете добавлять в интерфейс своего парсера дополнительные методы, возвращающие доп. информацию о текущем токене? В любом случае, архитектура вашего string parser'а будет требовать (завязана) информацию о классе, предоставляющем её (доп. информацию).

А теперь, (внезапно) вам понадобилось расширить возможности Вашего парсера.. Опять будете чего то добавлять в него? Писать доп. классы и т.д?
Этот процесс, при использованной Вами архитектуре, может вообще не закончится,  плодя различного рода зависимости между парсером и конкретными алгоритмами разбиения строки на токены.
И от этого, при данном подходе, не избавиться, как от крошек на кровати(

В то время, как решение boost::tokenizer позволяет и для такого случая (с доп. информацией) отдельно локализовать логику и интерфейс.

 
     

[Igors]

Первая архитектура которая приходит в голову

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

Здесь привлекает то что никаких зависимостей не создается. В общем, из этих соображений и был написан этот парсер. Однако сейчас (год спустя) мне не кажется что это "так уж хорошо". Особенно если исходная QString содержит много текстовых строк (разделенных EOL)

Какие есть мненмя?

[m_ax]

Первая архитектура которая приходит в голову

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

Здесь привлекает то что никаких зависимостей не создается. В общем, из этих соображений и был написан этот парсер. Однако сейчас (год спустя) мне не кажется что это "так уж хорошо". Особенно если исходная QString содержит много текстовых строк (разделенных EOL)

Какие есть мненмя?

если уж очень нужна доп. информация о токенах, то в подходе bоost::tokenizer я бы передавал (возможно опционально) в конструктор user_token_separator ссылку или указатель на объект token_details в которой уже на каждой итерации записывал необходимую информацию.

Код

C++ (Qt)
token_details details;
boost::tokenizer<user_token_separator> tok(str, user_token_separator(details));
for (auto s : tok) {
    if (details.is_quote) {...}
    //или да, записывать токены и соответствующую инфу о нём в некий контейнер.
 
}
 

Кода писал bib парсер я тоже записывал промежуточные токены в контэйнер и далее уже работал с ним.

[Igors]

Кода писал bib парсер я тоже записывал промежуточные токены в контэйнер и далее уже работал с ним.

Возникает суета с концами строк

// anything followed up to the line should ne ignored: " ' ( [ etc.

Уложить это в "цитату" не удается т.к. может быть 3 варианта EOL. Др случай

poly
...
...
face

Да, я знаю что есть "poly" но не умею или не хочу его разбирать - мне нужно пропускать все до тех пор пока строка не начнется с чего-то значащего для меня (напр "face")

В конце-концов просто найти "конец строки" сейчас тоже неудобно. Выходит так:
- если токен \n и следующий \r - это EOL Windows 
- если токен \n - это EOL Unix 
- если токен \r - это EOL Mac (старые файлы), но надо иметь ввиду предыдущий

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

[m_ax]

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

Могу в качестве примера bib_parser приаттачить..