Игнорирование комментариев при парсинге.

[Igors]

А теперь слегка усложним задачу.. Сейчас наш формат допускает наличие комментариев. Комментарий начинается с символа % и заканчивается концом строки.
Теперь, если какая то команда окажется в закоментированном блоке, то предыдущее решение по прежнему выцепит её..  Более того, коменты могут быть и внутри команды, что ещё попортит нам крови при разбиении на токены..

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

[m_ax]

А теперь слегка усложним задачу.. Сейчас наш формат допускает наличие комментариев. Комментарий начинается с символа % и заканчивается концом строки.
Теперь, если какая то команда окажется в закоментированном блоке, то предыдущее решение по прежнему выцепит её..  Более того, коменты могут быть и внутри команды, что ещё попортит нам крови при разбиении на токены..

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

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

Код

Bash
text text text \cite{arg1, %comment \n
arg2, % comment \n
...
% comment
} 
text text text % \cite {argN} \n
 
 

и т.д..

Вобщем не хочется мне думать при разборе ещё и о комментах..

[Igors]

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

Ну хорошо, надо регуляркой так надо. Тогда почему не так

- найти регуляркой команду (\cite)
- проверить не закомментирована ли она (просмотрев назад, если % да, если eol нет)
- заглотить токенайзером  все что в скобках и извлечь аргументы
- учесть отработанную позицию (}) для след регулярки

Для др комментариев (многострочных) решения нет. Напр если в середине файла непарная кавычка - она покроет все до конца, ну это решается постановкой.

---------------

По поводу концептуальности. Связавшись с тулзом/либой ее остается очень немного  Мы должны "принимать без доказательств" что вот это так - потому что оно так сделано и менять это нельзя. Усилия направлены на "прикручивание" т.е. добиться чтобы тулза делала что надо. Такое проектирование практически часто эффективно (но не всегда) и оно ограничено.

[Old]

Такое проектирование практически часто эффективно (но не всегда) и оно ограничено.

Практически часто редко ограниченно эффективно... Зато какие слова весомые.

Понимаете, вот ваш CTextAnalizer очень ограничен, он может делать только то, о чем вы думали в момент его создания. Без его модификации ничего нового он не сделает, ну это и не удивительно, если все засунуто в класс MainWindow, невозможно изменить поведение подсистемы не изменив сам класс.
Удачные решения состоят из кучи маленьких подсистем, которые делают исключительно свою работу. Поэтому, при таком концепте, легко можно изменить поведение одной подсистемы ничего более не меняя в остальной системе.
И совершенно не важно, применяется там буст или стд, можно не используя их писать удобные расширяемые решения. В данном случае мы обсуждаем итератор, в котором используются регулярки из boost, но никто не запрещает вместо них использовать регулярки Qt (или любые другие).

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

[m_ax]

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

Ну хорошо, надо регуляркой так надо. Тогда почему не так

- найти регуляркой команду (\cite)
- проверить не закомментирована ли она (просмотрев назад, если % да, если eol нет)
- заглотить токенайзером  все что в скобках и извлечь аргументы
- учесть отработанную позицию (}) для след регулярки

Потому что, это плохой костыльный подход, от которого я изначально хотел избавиться. Этот подход плох тем, что мне придётся переписывать логику разбора текста, захламляя код доп. проверками и т.п.. И всё равно это будет менее эффективно/медленнее работать.. Что если "смотреть назад" придётся очень далеко?
 

Для др комментариев (многострочных) решения нет. Напр если в середине файла непарная кавычка - она покроет все до конца, ну это решается постановкой.

А Вы не путаете цитаты (quote) с комментариями (comment)?

[Igors]

Потому что, это плохой костыльный подход, от которого я изначально хотел избавиться. Этот подход плох тем, что мне придётся переписывать логику разбора текста, захламляя код доп. проверками и т.п.. И всё равно это будет менее эффективно/медленнее работать.. Что если "смотреть назад" придётся очень далеко?

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

А Вы не путаете цитаты (quote) с комментариями (comment)?

Здесь нет принципиальной разницы: все это "экранированный" текст который должен быть считан как один токен (и вероятно пропущен)

[m_ax]

Речь идет о комментах "до конца строки", вычислительные расходы пренебрежимо малы и написать этот "просмотр вверх" - десяток строк.

Вот-вот.. У вас слегка изменилась задача и вам приходится по всему коду дописывать эти 10 строк с проверками и пр.
Далее, появится поддержка  многострочных комментов.. Будете писать ещё +10 (и если бы 10) строк по всему коду с доп. проверками и т.д..?

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

Что касается "идейности" то в упор не понимаю в чем же "костыльность" такого решения?

Ну здесь только грустный смайлик остаётся поставить(  
Old тоже выше уже писал почему это костыльное/ограниченное  решение..  
Вы вообще читаете предыдущие сообщения?

[m_ax]

Написал на Spiritе маленький парсер для извлечения из команд (\cite) списка ключей..
С поддержкой комментариев:

Код

C++ (Qt)
#include <boost/spirit/include/qi.hpp>
#include <boost/spirit/include/phoenix.hpp>
 
#include <string>
#include <functional>
#include <algorithm>
 
 
template <class Container>
bool add_unique_key(const std::string & key, Container & container)
{
    using namespace std::placeholders;
    if (std::find_if(container.begin(), container.end(), std::bind(std::equal_to<std::string>(), _1, key)) == container.end())
    {
        container.push_back(key);
        return true;
    }
    return false;
}
 
 
template <class ForwardIterator, class Container>
bool key_extractor(ForwardIterator & it, ForwardIterator end, Container & container)
{
    using namespace boost::spirit;
    namespace ph = boost::phoenix;
    namespace sn = boost::spirit::standard_wide;
 
    auto skipper = sn::space | '%' >> *(qi::char_ - (qi::eol | qi::eoi)) >> (qi::eol | qi::eoi);
    qi::rule<ForwardIterator, std::string(), decltype(skipper)> key, expr;
 
    key = +(qi::char_ - qi::char_(",{}%"));
    expr = qi::lexeme[qi::lit("\\cite")] >> '{'
        >>
        key[ ph::bind(&add_unique_key<Container>, qi::_1, ph::ref(container)) ] % ','
        >> '}'
        | qi::char_ ;
 
    return qi::phrase_parse(it, end, *expr, skipper) && (it == end);
}
 

 

И всё бы хорошо, если бы не одно но.. Как заставить skipper отличать начало комментария % от того, что началом комментария не является, т.е. \%
 

Или придётся на вход парсера свой skipper_iterator подавать? Не хотелось бы(

[Old]

Я сейчас далеко от компьютера, поэтому проверить не могу.
Попробуйте в скипере проверять вначале случай с экранированным % с помощью  оператора '!', тогда правило будет завершаться.

[m_ax]

Я сейчас далеко от компьютера, поэтому проверить не могу.
Попробуйте в скипере проверять вначале случай с экранированным % с помощью  оператора '!', тогда правило будет завершаться.

Уже пробовал(  
Но тогда началом коммента также будет считаться: любой символ кроме '\\' за которым следует '%'.
Это плохо, поскольку в следующей ситуации коммент "откусит" предыдущий символ (3):

text, text, \cite{key1, keq2, key3% start comment
, key4}  

Т.е. началом коммента будет 3%, что неправильно(

[Old]

Я имел ввиду проверять именно комбинацию из двух символов '\%'

[m_ax]

Я имел ввиду проверять именно комбинацию из двух символов '\%'

Так тоже не выходит..

Код

C++ (Qt)
nocom = qi::lit("\\%");
skipper = sn::space | !nocom >> '%' >> *(qi::char_ - (qi::eol | qi::eoi)) >> (qi::eol | qi::eoi);
 

По сути, это ни чем не отличается от просто

Код

C++ (Qt)
skipper = sn::space | '%' >> *(qi::char_ - (qi::eol | qi::eoi)) >> (qi::eol | qi::eoi);
 

[Old]

Я думал о чем то таком:

Код

C++ (Qt)
nocom = qi::lit("\\%");
skipper = sn::space | ( !nocom | '%' ) >> *(qi::char_ - (qi::eol | qi::eoi)) >> (qi::eol | qi::eoi);
 

Но можно попробовать добавить правило обработки комментариев в основной парсер вместо скипетра и игнорировать результат.

[Old]

Думал-думал. Все таки, пока не вижу, как это решить в скипере.
Сейчас попробую решить с правилом в основном правиле.

[m_ax]

Думал-думал. Все таки, пока не вижу, как это решить в скипере.
Сейчас попробую решить с правилом в основном правиле.

Похоже, что в Skipper не решит эту проблему в принципе(

Да, либо в правило в основном правиле или skipper_iterator