Здравствуйте, slava_phirsov, Вы писали:
_>Примеры — boost::optional (редкостный силос, ИМХО)
Почему? По моему, весьма простая и понятная (особенно, в использовании) штука. Вон и в стандарт её затащить хотят.
Здравствуйте, DarkEld3r, Вы писали:
DE>Почему? По моему, весьма простая и понятная (особенно, в использовании) штука. Вон и в стандарт её затащить хотят.
уже затащили. и any затащили, и filesystem. и сегодня еще std::apply(F&&, std::tuple<Types...>&&) затащили.
но кому оно надо, кто посмел ослушаться оракула?! =)
зы
так как отписаться от темы?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>уже затащили.
Вроде, ещё в С++14 хотели, но отложили? Или я что-то путают? Если "затащили"в С++17, то это ещё не совсем окончательно.
все что я перечислил — находится в транке, т.е. выйдет в пятой версии GCC. это С++14.
там выше я ошибся насчет неймспейса, оно все в std::experimental.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, Олег К., Вы писали:
ОК>Нормальному инженеру вообще такое в голову не прийдет использовать! ОК>Я, конечно же, допускаю что это может где-то понадобится но не на каждом шагу.
И что делать в таком случае? Искать "ненормального инженера"?
EP>>Но, такой же abuse происходит практически для каждой фичи. Например тот же "классический ООП" — раздуваются совершенно не нужные иерархии, да чего стоят только одни getters&setters в тех местах где достаточно обычной структуры. ОК>Нехорошо, конечно же, но жить можно. Главное чтобы код был понятен.
Развесистые иерархии (которые не к месту) усложняют понимание и использование. Точно также как и abuse TMP.
EP>>Выше по топику был пример использования Spirit
. Покажи где там нечитаемый код. ОК>Это был малюсенький кусочек кода. Не знаю где ты его взял и кто автор, но ты бы лучше скопировал кусок кода линий так на 30-40 тысяч как минимум.
Там ссылка есть на полный код, автор я.
ОК>Ну и вместо этой херни лучше уж написать небольшой парсер с рекурсивным спуском. Речь о небольших грамматиках.
А можно вместо сотен строк написать десятки. Причём где и что лучше зависит от ситуации
А вот априорно заявлять что один вариант хуже другого для всех ситуаций, при том что у каждого есть свои уникальные объективные преимущества — мягко говоря не разумно
ОК>И да, грамматики тоже надо дебагать.
В Spirit'е есть уже готовый подробный дамп процесса парсинга — почему, где и что сматчилось, а где нет.
Здравствуйте, nen777w, Вы писали:
N>Работал как то в такой, сказали что код должен быть расчитан на среднестатистического программиста и boost запретили использовать.
Очень правильное решение. С точки зрения коммерческой разработки ПО, а не с точки зрения cpp-гика, которому некуда тратить свободное время.
сорри, обшибся.
filesystem пока не закоммитили. просто на прошлой неделе в списке рассылки Jonatan Wakely постил реализацию, ее обсуждали. чем закончилось — не знаю. но, раз уж таки не закомитили — значит отправили на доработку.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, kurchatov, Вы писали:
N>>Работал как то в такой, сказали что код должен быть расчитан на среднестатистического программиста и boost запретили использовать. K>Очень правильное решение. С точки зрения коммерческой разработки ПО, а не с точки зрения cpp-гика, которому некуда тратить свободное время.
Где-то действительно есть смысл запрещать библиотеки, а где-то даже некоторые конструкции языка.
Но, задачи-то бывают совершенно разные — не пойму зачем распространять какие-то рецепты подошедшие лично тебе, в конкретном случае, на всю коммерческую разработку ПО?
Маленький пример — в одной части проекта (коммерческого!) мне понадобилась Fibonacci Heap, я взял boost::heap::fibonacci_heap и использую без всяких проблем — простой и понятный интерфейс. Что тут такого ужасного с твоей сферически-коммерческой точки зрения?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Маленький пример — в одной части проекта (коммерческого!) мне понадобилась Fibonacci Heap, я взял boost::heap::fibonacci_heap и использую без всяких проблем — простой и понятный интерфейс. Что тут такого ужасного с твоей сферически-коммерческой точки зрения?
да отлично! Я тоже люблю boost::lexical_cast
Spirit и прочий фьюжн — совершенно другой уровень и порог вхождения.
Здравствуйте, NeoCode, Вы писали:
NC>Я тоже не очень с этими шаблонами... вот прямо сейчас сижу разбираюсь. Просто раньше я как-то избегал излишнего метапрограммирования, а тут попался проект с достаточно глубоким уровнем применения матапрограммирования. Понемногу разбираюсь.
Главное понять, что шаблоны это функциональный язык.
Остальное просто.
NC>Но считаю что врага надо знать в лицо У меня тоже есть хобби — разработка своего языка программирования, не менее (и даже гораздо более) мощного чем С++, но без всей этой головной боли.
А можно подробнее?
Ибо у меня разработка языков не хобби.
NC>И для того чтобы это сделать наилучшим образом, считаю что нужно знать и С++ в совершенстве,
Лучше знать немерле.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, nen777w, Вы писали:
PM>>>не люблю Qt X>>да, это ужасное творение. но для ГУЯ приходится использовать, увы
N>Эм... и что в нём ужасного? Отличная библиотека, для GUI... так её и использую.
Для кросс-платформенного GUI других вариантов нет, так что с Qt приходится мириться. Мне Qt не нравится потому что:
Имеет достаточно давнюю историю и несет груз решений, принятых почти 20 лет назад из которых вытекают следующие пункты
Пытается быть мега-фреймворком со своими строками, сокетами, файлами и т.п.
Неоднозначная политика владения дочерними объектами
Жесткая связка модель-вид, где шаг влево или вправо от принятой концепции модели карается хаками в реализации views.
Я не слежу за развитием Qt Quick, так что может быть там все гораздо лучше. Но из моего скромного опыта использования, использовать Qt в С++ в 2014 году — это как MFC в начале 2000-х. Вроде бы и альтернатив нет, но уже устарело морально. Поэтому я предпочитаю проекты без GUI
PM>>>Высказывания "не используем boost потому что он слишком сложный" для меня признак низкой квалификации ведущего разработчика. Работать в такой команде — профессионально деградировать. X>>угу. N>Работал как то в такой, сказали что код должен быть расчитан на среднестатистического программиста и boost запретили использовать. N>Но я там не долго работал.
Я не зря упомянул ведущего. В команде могут быть новички, не очень опытные разработчики, которые не знают множества граблей С++, не дружат с Boost. Но если есть хоть один человек, для которого использовать Boost не проблема, и он умеет делиться своим знанием и помогать остальным (а это одна из основных ролей ведущего программиста), то он подтянет уровень остальных. Если такого человека нет, проект на С++ рано или поздно загнется. А неосилятор boost будет писать в интернете какой этот С++ сложный — от него сплошные утечки памяти и падения софта.
ps. Пока отвечал, тему уже в флейм снесли из-за одного тролля, который в разделе С++ особо и не отмечался
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, DarkEld3r, Вы писали:
X>все что я перечислил — находится в транке, т.е. выйдет в пятой версии GCC. это С++14. X>там выше я ошибся насчет неймспейса, оно все в std::experimental.
Ну раз эксперементальное, то всё-таки не C++14. Впрочем, я не сомневаюсь, что рано или поздно в стандарт оно всё-таки попадёт.
Мне Qt тоже не кажется идеальным фреймворком, но отдельные пунты не могу не прокомментировать.
PM>Имеет достаточно давнюю историю и несет груз решений, принятых почти 20 лет назад из которых вытекают следующие пункты
Само по себе это не недостаток. Скорее наоборот — тем более, что ряд классов/функций выкидывались переписывались, то есть нельзя сказать, что они не внедряют улучшения и тащат за собой легаси.
PM>Пытается быть мега-фреймворком со своими строками, сокетами, файлами и т.п.
Так ли это плохо? Скажем, строки у них весьма удобны. Ничего подобного в стандарте или даже бусте нет. Файлы тоже удобнее стандартных.
А их контейнеры совместимы с стлевскими алгоритмами и наоборот.
PM>Неоднозначная политика владения дочерними объектами
Она вполне однозначная в рамках фреймворка. (: В том смысле, что ничего неожиданного не происходит. Опять же, местами удобно.
PM>Жесткая связка модель-вид, где шаг влево или вправо от принятой концепции модели карается хаками в реализации views.
Ну это да. Хотя возможно "по старинке" пользоваться контролами без связки с модель/вью.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Недостаток языка — это отсутствие compile-time reflection, Boost.Fusion для этого предлагает макросы BOOST_FUSION_DEFINE_STRUCT и подобные. EP>А вот те методы работы, которые предлагает Boost.Fusion с уже адаптированными структурами (то есть для которые есть необходимые гетерогенные итераторы) — вполне себе, ничего костыльного.
Нуу тут вопрос вот в чём — если бы у нас уже была интроспекция в языке, то стали бы мы использовать подобное? Соответственно все варианты где ответ "нет не стали бы, но пока приходится" являются сильно костыльным. На мой вкус конечно же...
EP>Даже как-то сравнивали в этом отношении Boost.Fusion vs Nemerle vs D (Fusion
Здравствуйте, Олег К., Вы писали:
ОК>Ты видимо никогда не поддерживал код в который такие любители запихали Спирит. Иначе бы быстро поменял мнение.
Ну так я что бы ты запихал на их месте? ) Опишу задачку и свой вариант решения...
ОК>Жесть какая-то. Чтобы прочитать цсв Спирит не нужен!
Нужен/ненужен — это не разговор в мире разработки. Формально можно вообще всё на ассемблере написать и сказать что остальное не нужно. Разговор у нас идёт о минимизации усилий по написанию кода. Желательно при этом с одновременной максимизацией надёжности и быстродействия.
Здравствуйте, slava_phirsov, Вы писали:
_>А желающие — тратят его на написание каких-то своих шикарных костылей к готовым бустовским байкам. По сути так на так и выходит. Плюсы при использовании буста — человеку со стороны, знающему конкретную примененную часть буста проще понять код (ну, ему еще надо будет разобраться в прилагающихся костылях, но это, допустим, мелочи). Минусы — любое обобщенное решение сложно, а значит потенциально ненадежно и потенциально неоптимально. Примеры — boost::optional (редкостный силос, ИМХО) и boost::asio (без слез и мата работать с ним невозможно). Или вот, скажем, boost::circular_buffer. Ну просится, просится сделать не буфер, а просто адаптер-итератор, гораздо полезнее, ИМХО, но итератор — это не по-пацански, на нем не показать, что ты умеешь аллокаторы и move-semantics, потому и целый, извините, буфер.
Хыхы, кстати optional — это считай уже не boost, а стандарт языка. )))
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, slava_phirsov, Вы писали:
_>>А желающие — тратят его на написание каких-то своих шикарных костылей к готовым бустовским байкам. По сути так на так и выходит. Плюсы при использовании буста — человеку со стороны, знающему конкретную примененную часть буста проще понять код (ну, ему еще надо будет разобраться в прилагающихся костылях, но это, допустим, мелочи). Минусы — любое обобщенное решение сложно, а значит потенциально ненадежно и потенциально неоптимально. Примеры — boost::optional (редкостный силос, ИМХО) и boost::asio (без слез и мата работать с ним невозможно). Или вот, скажем, boost::circular_buffer. Ну просится, просится сделать не буфер, а просто адаптер-итератор, гораздо полезнее, ИМХО, но итератор — это не по-пацански, на нем не показать, что ты умеешь аллокаторы и move-semantics, потому и целый, извините, буфер.
_>Хыхы, кстати optional — это считай уже не boost, а стандарт языка. )))
Здравствуйте, PM, Вы писали:
PM>Для кросс-платформенного GUI других вариантов нет, так что с Qt приходится мириться.
Да ладно... Если говорить о чём-то сравнимом, то как минимум wxWidgets имеет такую же мощь и при этом без сомнительного извращения языка. Если же смотреть не только на такие глобальные фреймворки и не требовать обязательно нативных контролов (кстати, насколько я помню в Qt они и не такие, но хотя бы притворяются), то возникает ещё целая куча вариантов (gtk+/gtkmm, fltk, juce и т.д. и т.п.).
