Здравствуйте, pzhy, Вы писали:

P>>>Или для защиты запуска нескольких парсеров одновременно. Ну может быть... Хотя тоже не очень понятно зачем. По крайней мере дизасамблируя его в свое время я ничего подобного не видел. Но вообще он очень быстр, по крайней мере на простых парсерах. Я на первых порах просто офигел.

ТКС>>Да на простых парсерах там реально полезны только примитивы, которые вместо atoi и т.п. Все остальное получается без спирита в 2, ну пусть в 3 раза многословней, зато отлаживается и компилируется в лет.

P>А вы пишите свой парсер с нуля, или что то используете? Просто писать что то свое для ДСЛ, ну очень для меня сложно. flex/bison очень маштабно и обьемно. Но для своих целей самое то. Но и спирит во многих вещах рулит. Я как то переписал один парсер (был на стртоках) на нем получил 70% профита. Но ведь самое главное этот код потом менять можно, а тот только переписать

С нуля. Для xml совсем не страшно получилось. Хотя на счет в 2 раза многословней я конечно загнул Типа такого (в комментариях — оригинальный код для спирита):

/*  NameHead = (Letter | '_' | ':');
    NameTail = *NameChar ;
    Name =
      NameHead >> NameTail
    ;*/
    template <class Iter> bool Name(Iter &first, Iter last)
    {
        if (first == last)
            return false;
        Iter cur = first;
        if (NameHead(*cur))
            ++cur;
        else
            return false;
        for (; cur != last; ++cur)
            if (!NameChar(*cur))
                break;
        first = cur;
        return true;
    }
    template <class Iter, class Action> bool Name(Iter &first, Iter last, Action action)
    {
        Iter prev = first;
        if (Name(first, last))
        {
            action(prev, first);
            return true;
        }
        return false;
    }

/*    ClassIDAttribute = 
        str_p(CLASS_ID()) >> NameTail
        >> Eq 
        >> L'"'
        >> int_p [assign_object(rv.class_id.t)]
        >> L'"'
      ;*/
    match_string<wchar_t> strlit_class_id(L"class_id");
    match_string<wchar_t> strlit_reference(L"_reference");

    template <class Iter, class Action> bool ClassIDAttribute(Iter &first, Iter last, Action action)
    {
        Iter cur = skip_Sch(first, last);
        if (!strlit_class_id(cur, last))
            return false;
        strlit_reference(cur, last);    // it doesn't matter here - "class_id" or "class_id_reference" found.
        if (!Eq(cur, last))
            return false;
        if (!match_char<L'\"'>(cur, last))
            return false;
        if (!match_int(cur, last, action))
            return false;
        cur = skip_Sch(cur, last);
        if (!match_char<L'\"'>(cur, last))
            return false;
        first = cur;
        return true;
    }

Читается, конечно, похуже, зато отлаживается получше. И вполне модифицируемо/поддерживаемо в дальнейшем.

Здравствуйте, pzhy, Вы писали:

ТКС>>Собирать буст (конкретно, serialization) с этим дефайном под виндой — отдельное развлечение

P>А он так сильно нужен для вас? При крахе, не помню уже точно как на винде, все равно можно не успеть. А так не легче, ли свою синхронизацию сделать? Ведь все равно придется, но более наглядно

Кто сильно нужен? Буст? Очень. Мьютекс этот дурацкий? Без понятия, код не мой, раз автор воткнул синхронизацию — наверное, без нее будет редко-редко, но падать. А это неприемлемо.

Здравствуйте, Тот кто сидит в пруду, Вы писали:

Дефайн, этот конечно. Но если код не ваш, то да, менять опасно.
Но в вашем коде парсера, большая часть кода не представлена, если она писалась, не только для этого, то конечно игра стоит свечь. Если нет и неудовлетворяет спирит, то есть много других библиотек для ХМЛ. Но для более сложных, в плане грамматики, или контестного вызова функторов, мне кажется писать свой велосипед себе дороже. ИМХО.

Здравствуйте, pzhy, Вы писали:

P>Дефайн, этот конечно. Но если код не ваш, то да, менять опасно.

Да падало оно без этого дефайна пару раз просто, ЕМНИП.

P>Но в вашем коде парсера, большая часть кода не представлена, если она писалась, не только для этого, то конечно игра стоит свечь.

Да там всего что-то в районе 1100 строк получилось, из них наверное треть — комменты в виде старого спирит-парсера.

P>Если нет и неудовлетворяет спирит, то есть много других библиотек для ХМЛ. Но для более сложных, в плане грамматики, или контестного вызова функторов, мне кажется писать свой велосипед себе дороже. ИМХО.

Не-не-не. Требовалась полная совместимость с парсером из boost.serialization — чтобы после его замены все, что пользователи успели насохранять нашей программой, прочиталось. Поэтому сторонние библиотеки сразу отпали. Свое писалось пару дней и дня три — неделю отлаживалось — на поиск подходящей библиотеки я бы наверняка больше потратил, без каких-либо гарантий достижения нужного результата.
А контекстный вызов функторов делается при таком подходе на раз, я же как раз пример привел. Что касается сложных грамматик или быстрого разбора, то не о них речь — спирит же заявляется как recursive descent parser generator. Ну а рекурсивный спуск и без него тривиально пишется.

Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>А контекстный вызов функторов делается при таком подходе на раз, я же как раз пример привел. Что касается сложных грамматик или быстрого разбора, то не о них речь — спирит же заявляется как recursive descent parser generator. Ну а рекурсивный спуск и без него тривиально пишется.

С позиционным итератором (строка, колонка) начального и коечного эдемента блока? Очень сильно в ваш код не вглядывался

Здравствуйте, pzhy, Вы писали:

ТКС>>А контекстный вызов функторов делается при таком подходе на раз, я же как раз пример привел. Что касается сложных грамматик или быстрого разбора, то не о них речь — спирит же заявляется как recursive descent parser generator. Ну а рекурсивный спуск и без него тривиально пишется.

P>С позиционным итератором (строка, колонка) начального и коечного эдемента блока? Очень сильно в ваш код не вглядывался

Какая еще строка-колонка? Нет у меня в коде такого, ибо не требовалось. И вопрос я кстати не понял.

Здравствуйте, Aleх, Вы писали:

A>Здравствуйте, blackhearted, Вы писали:

B>>Здравствуйте, Aleх, Вы писали:


P>>>>>>Использовал, только boost::spirit. Скорость в рантайме впечатляет(например парсинг числа быстрее чем atoi,ftoi и т.д)

A>>>>>Ну и вообще, сами подумаете, было бы глупо, если бы вручную написанны функции на голом Си (в Spirit функции чтения числа, впрочем, тоже написаны вручную) работали бы на порядок медленнее чем шаблонные нагромождения Boost.

B>>>>Я что-то не пойму каким образом производительность в рантайме связана с шаблонами, которые инстанцируются в compile-time?

A>>>А очень простым. Понимаете ли, мы живем не в идеальном мире, в котором всё на практике точно так же, как и в теории. Компиляторы часто написаны так, что плохо переваривают шаблонный код. Особенно плохо (я бы сказал отвратительно) это делает компилятор Intel. То есть на одном проекте (с большим количеством шаблонного кода) я встретился с тем, что msvc и gcc компилировали код на ура (и всё хорошо работало), а компилятор Intel (какие бы я настройки на пробовал) компилировал проект в значительно худший (медленный) код (причем кода получалось раз в 10 больше). И не надо мне говорить по поводу размера кода то, что возможно туда добавились библиотеки.

B>>Никто не спорит, что если под вашу платформу и компилятор boost давал значительно худший (кстати — это в каких единицах?) код — то флаг вам в руки, пишите всё сами и не используёте boost.

A>Я бы сказал во всех: скорость выполнения, размер кода, время компиляции.
A>Boost и не использовался, хотя код всё равно был похож на внутренности буста.
A>Проблема была только в компиляторе Intel. Кстати, интересно, как он компилирует Boost?

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

dabeat_bf, blackhearted, мне даже стало интересно, из-за чего смешно вам стало?