Тут задавали вопросы про сферический коммерческий код, типа что это такое и как он выглядит. Далее две ссылки, реализующие разные принципы построения парсеров, какой из них, по мнению здешней публики, больше достоен приниматься за эталон понятия "коммерческого кода".
1 более-менее понятно, хотя кода дофига. 2 вообще непонятно ничего. 1 лучше. А лучше написать кодогенератор, который сгенерирует код, похожий на 1 вариант из читабельного формата.
Здравствуйте, vsb, Вы писали:
vsb>1 более-менее понятно, хотя кода дофига. 2 вообще непонятно ничего. 1 лучше. А лучше написать кодогенератор, который сгенерирует код, похожий на 1 вариант из читабельного формата.
Да. В многих либах Boost-а вообще самый запутаный код, который мне приходилось изучать. В исходниках некоторых либ из boost-а, таких как boost::asio или boost::coroutine, всё хорошо понятно, но вот Spirit-это пример ужаса на крыльях ночи. Этот примёр только фрагмента файла из Spirit-а, дерево каталогов этой либы ещё более запутанно, всё раскидано по разным закоулкам и все закоулки с одинаковым названиями файлов и директорий, как будто специально что-то пытаются спрятать, или просто пишут очень небрежно, сваливая куда придётся в пределах дерева. Но, возможно сейчас появятся фанаты boost-а (Nixman), и расскажут, что это так и должно быть.
Здравствуйте, smeeld, Вы писали:
S>Тут задавали вопросы про сферический коммерческий код, типа что это такое и как он выглядит. Далее две ссылки, реализующие разные принципы построения парсеров, какой из них, по мнению здешней публики, больше достоен приниматься за эталон понятия "коммерческого кода".
Да никакой, ибо сам вопрос — глупый! Нет такого "коммерческого" кода. Есть задачи и целая куча параметров, влияющих на будущий код. Одна и та же "сортировка" может быть сделана 10 разными способами (не алгоритмом!), в зависимости от требований. Например:
а) программа нужна "ещё вчера", поэтому БЫСТРО делай любой прототип, лишь бы выход был корректный. Критерий — скорость разработки, шаблоны и космические архитектуры идут лесом.
б) программу будет поддерживать школьный учитель, поэтому код должен быть простой и даже без классов.
в) программа нужна для embedded, поэтому у тебя есть две переменных и 1КБ памяти — как хочешь, так и пиши.
г) программа нужна для выпендрёжа на RSDN, поэтому насуй туда побольше templates — люди это любят.
Ну и какой смысл при абсолютно неизвестных критериях сравнивать два шмота кода?? Вы, товарищ smeeld, сколько месяцев в программировании?
K>Да никакой, ибо сам вопрос — глупый! Нет такого "коммерческого" кода.
Ну, это чисто для прикола, на этом форуме иногда появлялись начинающие, которые спрашивали как выглядит "типичный коммерческий код", типа умение писать именно такой код есть требование для успешного трудоустройства. Но те два примера интересны ещё как пример различия дизайнов, первый есть олдскульный C-like, второй есть modern C++, в которой даже запятые являются шаблонными классами. Какой из них более предпочителен в 2017 году? Прошу высказаться.
Здравствуйте, smeeld, Вы писали:
S>Далее две ссылки, реализующие разные принципы построения парсеров, какой из них, по мнению здешней публики, больше достоен приниматься за эталон понятия "коммерческого кода".
Сравнение некорректно, потому что приведённый пример кода в стиле C является парсером конкретного протокола, а пример кода в стиле современного C++ является универсальным средством для построения произвольных парсеров. Если есть желание продемонстрировать честный аналог Spirit'a в стиле C, то надо взять исходники Bison + Flex.
P.S. Если бы в моём проект стоял выбор между использованием Bison + Flex и Spirit, то скорее всего я бы предпочёл последнее, в силу более удобного API.
Здравствуйте, vsb, Вы писали:
vsb>1 более-менее понятно, хотя кода дофига. 2 вообще непонятно ничего. 1 лучше. А лучше написать кодогенератор, который сгенерирует код, похожий на 1 вариант из читабельного формата.
Хыхы, вот как раз данный вариант2 и является фрагментом "кодогенератора, который генерирует код из читабельного формата". )))
хех, а вам-то какое до них дело? Когда они вырастут профессионально, они сами поймут, что любой код может оказаться "правильным". А показывать примеры сейчас — только ещё больше их запутывать, ибо критерии "лучшести" неизвестны.
S> Но те два примера интересны ещё как пример различия дизайнов .... Какой из них более предпочителен в 2017 году?
Критерии лучшести не зависят от года. Выше я привёл 4 критерия, по которым любая программа может оказаться ужасной, хотя и написанной по всем канонам.
Если говорить о самых минимальных критериях, программа должна быть ПОДДЕРЖИВАЕМОЙ, что включает в себя простоту кода, лёгкое переиспользование и заимствование кода. Этот критерий работает как для профи, так и для любых хобби-проектов.
Здравствуйте, alex_public, Вы писали:
_>Сравнение некорректно, потому что приведённый пример кода в стиле C является парсером конкретного протокола, а пример кода в стиле современного C++ является универсальным средством для построения произвольных парсеров. Если есть желание продемонстрировать честный аналог Spirit'a в стиле C, то надо взять исходники Bison + Flex.
+1
Зануда мод он: не "исходники Bison + Flex", и сгенеренный ими код/API и входную грамматику.
_>P.S. Если бы в моём проект стоял выбор между использованием Bison + Flex и Spirit, то скорее всего я бы предпочёл последнее, в силу более удобного API.
Где здесь "коммерция"? Упустим, что это вообще несравнимый код.
Первый — "честно скоммунизденный" код из продукта, по волею случая ставшего "почти чуть" коммерческим.
Второй — частичка части монстра, развиваемого сообществом.
Здравствуйте, Skorodum, Вы писали:
_>>Сравнение некорректно, потому что приведённый пример кода в стиле C является парсером конкретного протокола, а пример кода в стиле современного C++ является универсальным средством для построения произвольных парсеров. Если есть желание продемонстрировать честный аналог Spirit'a в стиле C, то надо взять исходники Bison + Flex. S>+1 S>Зануда мод он: не "исходники Bison + Flex", и сгенеренный ими код/API и входную грамматику.
Нет, как раз аналогом исходников Spirit будут исходники Bison + Flex. Аналогом входной грамматики будет исходный код (обычно несколько строк), использующий Spirit. А сгенерированным кодом/API будет то, вот что компилятор раскроет все эти шаблоны при компиляции кода, использующего Spirit.
Здравствуйте, fin_81, Вы писали:
_>Второй — частичка части монстра, развиваемого сообществом.
Он, этот монстр, в коммерческих проектах задействуется стохановскии темпами. Сейчас почти всё коммерческое, что пишется на C++, обязательно содержит код из буста, тенденция только нарастает. Верно и обратное, сам boost представляет собой собрание наработок, сделанных в разработке различных проектов разработки коммерческого софта.
Здравствуйте, smeeld, Вы писали:
S>Он, этот монстр, в коммерческих проектах задействуется стохановскии темпами. Сейчас почти всё коммерческое, что пишется на C++, обязательно содержит код из буста, тенденция только нарастает.
Ну так это и логично. Если бы скажем реализовать с помощью Spirit парсер из твоего первого примера, то он гарантированно занял бы в разы меньше кода, причём максимально красивого (в котором чётко видно отдельное описание формата).
Здравствуйте, alex_public, Вы писали:
_>Ну так это и логично. Если бы скажем реализовать с помощью Spirit парсер из твоего первого примера, то он гарантированно занял бы в разы меньше кода, причём максимально красивого (в котором чётко видно отдельное описание формата).
Чёрта с два он будет производительней, если использовать стандартную схему с построением дерева в контейнерах на основе правил qi::grammar, и последующем его обходе. В первом же случае переходы парсинга определяется по ходу чтения байтов-символов с сырого текста, и по достижению спайса уже известно куда идти дальше. Если такую схему реализовать spirit-ом, то получится то же самое, только записанное в ином стиле: цикл будет не в стиле
Какой из методов более предпочтителен, в этом и есть суть вопроса в треде, олдскульный while(){}, или в стиле фантазий разрабов буста, в виде type type type.
Здравствуйте, smeeld, Вы писали:
_>>Второй — частичка части монстра, развиваемого сообществом.
S>Он, этот монстр, в коммерческих проектах задействуется стохановскии темпами. Сейчас почти всё коммерческое, что пишется на C++, обязательно содержит код из буста, тенденция только нарастает. Верно и обратное, сам boost представляет собой собрание наработок, сделанных в разработке различных проектов разработки коммерческого софта.
Люблю аналогии.
Сейчас все коммерческое, сто пишется на С++, обязательно содержит оператор префиксного инкремента, тенденция только нарастает. Верно и обратное, само использование префиксного инкремента есть следствие нароботок, сделанных в разработке коммерческого софта.
Какой вывод? Префиксный инкремент — это коммерческий софт?
Второй вопрос, первый листинг — это пример коммерческого или некоммерческого софта?
В-нулевых, где здесь "коммерция"?
Во-первых, ты сравниваешь не сравнимое, генератор парсера на так-скажем тьюринг-полном языке шаблонов С++ сравниваешь с конкретной реализацией.
Во-вторых, опять сравниваешь несравнимое, неэквивалентный код так-скажем императивного цикла while и так-скажем функциональный стиль метапрограммирования на шаблонах.
Здравствуйте, fin_81, Вы писали:
_>В-нулевых, где здесь "коммерция"?
А вот это и хотел бы узнать, что для "типично коммерческого" более приемлемо.
_>Во-первых, ты сравниваешь не сравнимое, генератор парсера на так-скажем тьюринг-полном языке шаблонов С++ сравниваешь с конкретной реализацией.
Там, вообще говоря, неважно, реализация чего именно там. Приводились примеры дизайна кода, и спрашивалось, какой из них более предпочтителен в 2017 в разработке на C++ в проектах коммерческого кода (тот, что за бабки будет продаваться).
_>Во-вторых, опять сравниваешь несравнимое, неэквивалентный код так-скажем императивного цикла while и так-скажем функциональный стиль метапрограммирования на шаблонах.
Вот для того и сравниваю, чтоб узнать мнение местной публики, какой из них предпочтительней для, см. выше.
Вы, товарищ smeeld, сколько месяцев в программировании?
Когда они вырастут профессионально, они сами поймут, что любой код может оказаться "правильным". А показывать примеры сейчас — только ещё больше их запутывать, ибо критерии "лучшести" неизвестны.
