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

P>Здравствуйте, Аноним, Вы писали:

А>>Кто что может сказать по поводу
А>>1) Chilon
А>>2) pegtl

А>>в плане удобности использования/простоты/надежности/скорости etc.
А>>а также по сравнению с boost::spirit

А>>масштаб — начиная от сложных конфигурационных файлов до фронтендов

P>Использовал, только boost::spirit. Скорость в рантайме впечатляет(например парсинг числа быстрее чем atoi,ftoi и т.д).
Существует мнение, что Spirit и atoi/ftoi не одинакововы по функциональности. Точнее, Spirit не охватывает всей функциональности atoi/ftoi. А именно, вторые функции преобразуют строки в числа в зависимости от настроек языка в системе.

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

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

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


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

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

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

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

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

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

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

Кто что может сказать по поводу
1) Chilon
2) pegtl

в плане удобности использования/простоты/надежности/скорости etc.
а также по сравнению с boost::spirit

масштаб — начиная от сложных конфигурационных файлов до фронтендов

Здравствуйте, Аноним, Вы писали:

А>Кто что может сказать по поводу
А>1) Chilon
А>2) pegtl

А>в плане удобности использования/простоты/надежности/скорости etc.
А>а также по сравнению с boost::spirit

А>масштаб — начиная от сложных конфигурационных файлов до фронтендов

Использовал, только boost::spirit. Скорость в рантайме впечатляет(например парсинг числа быстрее чем atoi,ftoi и т.д). В Испльзовании, на любителя, но не так сложно как кажется. Надежность — ну не очень понятно, что имеется ввиду. Первый аналог, отмел бы сразу — так как C++0x Library. Будет еще очень сырая. Вторая — тоже самое. все ИМХО.
Не знаю что такое "фронтенд" но если имеется в виду DSL, то писать на спирите можно(про "сложных конфигурационных файлов" без вопрсов). Если правила DSL очень сложны, то я бы посмотрел в сторону flex/bison

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

P>Использовал, только boost::spirit. Скорость в рантайме впечатляет(например парсинг числа быстрее чем atoi,ftoi и т.д). В Испльзовании, на любителя, но не так сложно как кажется. Надежность — ну не очень понятно, что имеется ввиду. Первый аналог, отмел бы сразу — так как C++0x Library. Будет еще очень сырая. Вторая — тоже самое. все ИМХО.
P>Не знаю что такое "фронтенд" но если имеется в виду DSL, то писать на спирите можно(про "сложных конфигурационных файлов" без вопрсов). Если правила DSL очень сложны, то я бы посмотрел в сторону flex/bison

+1

только одно замечание: имхо, смотреть в сторону flex/bison имеет смысл только если гонишься за скоростью либо генерацией парсеров на нескольких языках, в остальном спирит в плане интеграции с твоим кодом удобнее будет. Особенно Спирит2.

You will always get what you always got
  If you always do  what you always did

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

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

P>>Здравствуйте, Аноним, Вы писали:

А>>>Кто что может сказать по поводу
А>>>1) Chilon
А>>>2) pegtl

А>>>в плане удобности использования/простоты/надежности/скорости etc.
А>>>а также по сравнению с boost::spirit

А>>>масштаб — начиная от сложных конфигурационных файлов до фронтендов

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

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

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

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

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

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

P>>>Здравствуйте, Аноним, Вы писали:

А>>>>Кто что может сказать по поводу
А>>>>1) Chilon
А>>>>2) pegtl

А>>>>в плане удобности использования/простоты/надежности/скорости etc.
А>>>>а также по сравнению с boost::spirit

А>>>>масштаб — начиная от сложных конфигурационных файлов до фронтендов

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

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

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

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

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


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

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

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

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

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

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

J>только одно замечание: имхо, смотреть в сторону flex/bison имеет смысл только если гонишься за скоростью либо генерацией парсеров на нескольких языках, в остальном спирит в плане интеграции с твоим кодом удобнее будет. Особенно Спирит2.

По скорости в рантайме, думаю спирит будет быстрее. Спирит2, я так и не нашел как к обработчику прикрутить позиционный итератор. Хотя не так долго искал.

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

P>>Использовал, только boost::spirit. Скорость в рантайме впечатляет(например парсинг числа быстрее чем atoi,ftoi и т.д).
A>Существует мнение, что Spirit и atoi/ftoi не одинакововы по функциональности. Точнее, Spirit не охватывает всей функциональности atoi/ftoi. А именно, вторые функции преобразуют строки в числа в зависимости от настроек языка в системе.

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

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

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

J>>только одно замечание: имхо, смотреть в сторону flex/bison имеет смысл только если гонишься за скоростью либо генерацией парсеров на нескольких языках, в остальном спирит в плане интеграции с твоим кодом удобнее будет. Особенно Спирит2.

P>По скорости в рантайме, думаю спирит будет быстрее. Спирит2, я так и не нашел как к обработчику прикрутить позиционный итератор. Хотя не так долго искал.

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

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

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

J>>>только одно замечание: имхо, смотреть в сторону flex/bison имеет смысл только если гонишься за скоростью либо генерацией парсеров на нескольких языках, в остальном спирит в плане интеграции с твоим кодом удобнее будет. Особенно Спирит2.

P>>По скорости в рантайме, думаю спирит будет быстрее. Спирит2, я так и не нашел как к обработчику прикрутить позиционный итератор. Хотя не так долго искал.

ТКС>В спирите раньше был глобальный мьютекс (сейчас не знаю), который иногда здорово просаживал производительность.

Интересно, с чем же он конкурировал? Он что парсит в несколько потоков? Когда вешал его, то почему-то видел 100% занятие только одного ядра. Но если все же в несколько потоков, то респект разрабам. Да только по всей логике, так быть не может. Вы с чем то путаете

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

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

J>>>только одно замечание: имхо, смотреть в сторону flex/bison имеет смысл только если гонишься за скоростью либо генерацией парсеров на нескольких языках, в остальном спирит в плане интеграции с твоим кодом удобнее будет. Особенно Спирит2.

P>>По скорости в рантайме, думаю спирит будет быстрее. Спирит2, я так и не нашел как к обработчику прикрутить позиционный итератор. Хотя не так долго искал.

ТКС>В спирите раньше был глобальный мьютекс (сейчас не знаю), который иногда здорово просаживал производительность.

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

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

J>>>>только одно замечание: имхо, смотреть в сторону flex/bison имеет смысл только если гонишься за скоростью либо генерацией парсеров на нескольких языках, в остальном спирит в плане интеграции с твоим кодом удобнее будет. Особенно Спирит2.

P>>>По скорости в рантайме, думаю спирит будет быстрее. Спирит2, я так и не нашел как к обработчику прикрутить позиционный итератор. Хотя не так долго искал.

ТКС>>В спирите раньше был глобальный мьютекс (сейчас не знаю), который иногда здорово просаживал производительность.

P>Интересно, с чем же он конкурировал? Он что парсит в несколько потоков?

У меня в программе сериализация в xml в несколько потоков, соответственно и парсить надо было в несколько потоков.

P>Когда вешал его, то почему-то видел 100% занятие только одного ядра. Но если все же в несколько потоков, то респект разрабам. Да только по всей логике, так быть не может. Вы с чем то путаете

Сейчас проверил — в версии 1.42 данный мьютекс по-прежнему в наличии, ищется по макросу BOOST_SPIRIT_THREADSAFE. Хотя раньше вроде как-то слегка по другому там все было. На кой черт он понадобился в object_with_id_base — понятия не имею. Я при возникновении проблемы просто переписал xml-парсер без спирита, благо были и другие показания (рекурсивное правило, которое я не знал как переписать со спиритом без рекурсии и которое иногда роняло программу). Стало быстрее.

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

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

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

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

J>только одно замечание: имхо, смотреть в сторону flex/bison имеет смысл только если гонишься за скоростью либо генерацией парсеров на нескольких языках, в остальном спирит в плане интеграции с твоим кодом удобнее будет. Особенно Спирит2.

Да еще один минус спирита, на нем покрайней мере года 2 назад, невозможно было описать граматику плюсов. Т.е. теритически возоможно, но ни один компилятор не справлялся со всеми 180 правилами. Ну скорость компиляции, это нечто. Простой ДСЛ описаный на спирите прибавлял у меня 10 минут. Хотя в рантайме он очень крут

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

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

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

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

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

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

ТКС>Сейчас проверил — в версии 1.42 данный мьютекс по-прежнему в наличии, ищется по макросу BOOST_SPIRIT_THREADSAFE.
У меня походу собрана без этого дефайна. Прикольно. Linux Fedora 13.

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

ТКС>>Сейчас проверил — в версии 1.42 данный мьютекс по-прежнему в наличии, ищется по макросу BOOST_SPIRIT_THREADSAFE.
P>У меня походу собрана без этого дефайна. Прикольно. Linux Fedora 13.

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

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

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

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

Здравствуйте, 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, мне даже стало интересно, из-за чего смешно вам стало?