Во почитал тут про просьбу накидать извратов в С++
И встал вопрос — зачем все это?
Я всю жизнь прогаю на С++, но никак не пойму — зачем писать код, который, чтобы понимать, надо хрен знает сколько знать?
Столкнулся когда-то по работе с любителем буста. Ну это ж просто трындец какой-то. Какой-нить хитрожопый бинд и код запутывается так, что хрен потом разберешься
Это я только пример привел, таких примеров куча
И не надо говорить, что я старый пердун и не хочу разбираться в новых технологиях и веяниях
С++ — это всего лишь молоток, который дан вам в руки. Когда люди начинают хвастаться, что умеют делать молотком массаж простаты с одновременным пломбированием зубов — ну что ж — флаг вам в руки
Здравствуйте, Qbit86, Вы писали:
Q>У меня для тебя плохая новость
У меня для тебя тоже плохая новость. Не в первый раз сталкиваюсь с твоим задором неофита, хотя вроде бы ты не студент. Так вот, по моему мнению, разработчик проходит три этапа:
1. Он еще мало, что знает и пишет так как может
2. Ему кажется, что он уже многое знает и тут начинаются трюки, стремление вместить побольше паттернов, обожествление Буста и Александреску
3. Он действительно знает и умеет, поэтому пишет простой, понятный и расширяемый код
А теперь ссылка на столь почитаемых тобой авторитетов:
Отладка — вдвое более сложный процесс, чем написание кода с нуля. Поэтому, если Вы пишите код на грани своих умственных сил, Вы по определению не будете достаточно умны, чтобы отладить его.
хъ
A>Я всю жизнь прогаю на С++, но никак не пойму — зачем писать код, который, чтобы понимать, надо хрен знает сколько знать?
А меня все время мучает другой вопрос — нахрена писать код, в котором конечно ничего из знания языка кроме scanf знать не надо, но банальный парсер который на спирите пишется влет и занимает 50 строк вместе с вменяемой обработкой ошибок из коробки, занимает в конечном итоге сторок 500 и не падает только на тшательно подобранных входных данных?
A>Столкнулся когда-то по работе с любителем буста. Ну это ж просто трындец какой-то. Какой-нить хитрожопый бинд и код запутывается так, что хрен потом разберешься
Лютый батхерт человека, который пытается отлаживать бинд по типу степ-инто, чуствую я.
Здравствуйте, Anpek, Вы писали:
A>Столкнулся когда-то по работе с любителем буста. Ну это ж просто трындец какой-то. Какой-нить хитрожопый бинд и код запутывается так, что хрен потом разберешься
У меня для тебя плохая новость: «хитрожопый бинд» переехал из Буста в Стандарт, теперь ты будешь встречать его всё чаще.
A>И не надо говорить, что я старый пердун и не хочу разбираться в новых технологиях и веяниях
Почему не надо? Брюзжание про «любителей Буста» именно так и выглядит.
A>С++ — это всего лишь молоток, который дан вам в руки. Когда люди начинают хвастаться, что умеют делать молотком массаж простаты с одновременным пломбированием зубов — ну что ж — флаг вам в руки
Вгоняет в ступор бинд — ну что ж — плохо быть тобой. По возможности избегайте этого.
Здравствуйте, Qbit86, Вы писали:
Q>Я пишу на разных языках, и C++ вовсе не самый предпочтительный. Буст и новый Стандарт — это вещи, которые делают процесс написания на C++ хоть сколь-нибудь сносным. Их наличие — этот тот минимум, с которым я ещё готов браться за C++.
Не надо. Не надо браться за С++, если не готов учиться писать на С++, как это надо делать на С++, и всем будет лучше, а говнокода в мире появится меньше
Q>Использование большей части Буста не требует приложения чрезвычайных умственных усилий. Но использование Boost.Bind всё-таки предполагает понимание концепций функций высших порядков и замыканий. Если Boost.Bind вызывает сложности, то это скорее проблема не Буста, а понимания идей, за ним лежащих. Возможно, стоит начать с чего-то попроще, со Scala/C#/F#/Python (и не побоюсь этого слова Haskell). После этого суть «хитрожопых биндов» будет проще разглядеть за вырвиглазным плюсовым синтаксисом.
Ты рассказываешь о своих личных интеллектуальных трудностях, и твоей личной истории их преодоления, а не о проблемах бустовых биндов..
Проблема биндов в том, что если что-то не работает, то отлаживаться неудобно, а не в понимании концепции замыканий и функций, оперирующих с функциями...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, MTD, Вы писали:
MTD>Не в первый раз сталкиваюсь с твоим задором неофита, хотя вроде бы ты не студент.
Это не задор неофита. Это неприязнь к луддитам.
Я пишу на разных языках, и C++ вовсе не самый предпочтительный. Буст и новый Стандарт — это вещи, которые делают процесс написания на C++ хоть сколь-нибудь сносным. Их наличие — этот тот минимум, с которым я ещё готов браться за C++.
MTD>Так вот, по моему мнению, разработчик проходит три этапа:
В классической формулировке эти три этапа звучат так:
1) Не уметь использовать.
2) Уметь использовать.
3) Уметь не использовать.
MTD>
MTD>Отладка — вдвое более сложный процесс, чем написание кода с нуля. Поэтому, если Вы пишите код на грани своих умственных сил, Вы по определению не будете достаточно умны, чтобы отладить его.
MTD>Брайан Керниган
Использование большей части Буста не требует приложения чрезвычайных умственных усилий. Но использование Boost.Bind всё-таки предполагает понимание концепций функций высших порядков и замыканий. Если Boost.Bind вызывает сложности, то это скорее проблема не Буста, а понимания идей, за ним лежащих. Возможно, стоит начать с чего-то попроще, со Scala/C#/F#/Python (и не побоюсь этого слова Haskell). После этого суть «хитрожопых биндов» будет проще разглядеть за вырвиглазным плюсовым синтаксисом.
Здравствуйте, MTD, Вы писали:
MTD>А теперь ссылка на столь почитаемых тобой авторитетов: MTD>
MTD>Отладка — вдвое более сложный процесс, чем написание кода с нуля. Поэтому, если Вы пишите код на грани своих умственных сил, Вы по определению не будете достаточно умны, чтобы отладить его.
MTD>Брайан Керниган
Возможно. Не имею возможности проверить лично ввиду того, что собственный код отлаживать не приходится. Но вот что совершенно точно, та это то, что отладка — очень медленный, малоэффективный и совершенно не поддающийся автоматизации процесс. Поэтому я, например, пишу для своего кода юнит-тесты. Отладкой собственного кода приходится заниматься ровно в двух случаях. Когда результаты юнит-теста попахивают чертовщиной, что бывает исключительно в случаях, когда тест покрывает код из сторонней либы, к которой пока совершенно непонятно, как подступиться и когда банально интересно, во что оно там в итоге скомпилировалось после всех оптимизаций.
Это скорее к недавней теме о юнит-тестах из соседнего форума.
Здравствуйте, Qbit86, Вы писали:
Q>Использование большей части Буста не требует приложения чрезвычайных умственных усилий.
БЛИИИИИИННННН
Не про это топик!!! Вот людям сказать — ГРУША — так они ничего не видят кроме этого
Я не про бинд говорил!!!! Посмотри в заголовок!! Что думаешь я не понимаю что такое i++?
Я писал про ИЗВРАТЫ в применении С++!!!!!
Здравствуйте, Qbit86, Вы писали:
Q>Ок. Просто «любители Буста» звучало несколько провокационно и пренебрежительно.
Дык "профессионалы буста" -- это вообще диагноз
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, landerhigh, Вы писали:
L>>Но вот что совершенно точно, та это то, что отладка — очень медленный, малоэффективный и совершенно не поддающийся автоматизации процесс.
MTD>Коллега, с этим спорить невозможно.
Спасибо, я старался
L>>Поэтому я, например, пишу для своего кода юнит-тесты.
MTD>Я тоже пишу, но они иногда не работают, а иногда работают, но не работает программа (почему вопрос для отдельной темы).
Ну, у нас если юнит-тесты не работают, то билд банально не проходит. Они, впрочем, не панацея и иногда система все же не работает, но это и правда вопрос для отдельной темы.
L>>Отладкой собственного кода приходится заниматься ровно в двух случаях.
MTD>Здесь надо уточнить, что подразумевается под отладкой, если трассировка в отладчике, то я этим занимаюсь от силы раз в пол года, но с другой стороны я часто медитирую над логами — это отладка?
Думаю, что как Кернинган, так и большинство соучаснегов этого форума под отладкой понимают таки трассировку.
А по поводу логов — смотря что за логи. Если это логи типа "захожу в функцию, выхожу из функции, ой упало" (такое видел и не раз) — то это недалеко ушло от сиденья в дебаггере.
А вот если это пользовательский лог "не могу подключиться, потому что удаленный хост не отвечает" или инженерный, позволяющий легко восстановить последовательность событий вроде "отправили пакет А — получили ответ и успешно его обработали, отправили пакет Б — получили тонну каких-то кракозябр, которые разобрать не можем и посему отключились от греха подальше", то это уже совсем другое дело и порой без этого вообще никак.
Здравствуйте, Qbit86, Вы писали: Q>У меня для тебя плохая новость: «хитрожопый бинд» переехал из Буста в Стандарт, теперь ты будешь встречать его всё чаще.
если что-то переехало в стандарт, то не факт что люди будут этим пользоваться. вон, auto_ptr или deque сто лет в стандарте и никто их не использует
Здравствуйте, Qbit86, Вы писали:
Q>У меня для тебя плохая новость: «хитрожопый бинд» переехал из Буста в Стандарт, теперь ты будешь встречать его всё чаще.
Зачем бы это, при живых-то лямбдах?
Q>Почему не надо? Брюзжание про «любителей Буста» именно так и выглядит.
Например потому, что это переход на личности...
Q>Вгоняет в ступор бинд — ну что ж — плохо быть тобой. По возможности избегайте этого.
В ступор вгоняет не бинд, а его применение не по делу.
По идее продвинутые средства должны удешевлять поддержку кода, а не удорожать её...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Qbit86, Вы писали:
Q>У меня для тебя плохая новость: «хитрожопый бинд» переехал из Буста в Стандарт, теперь ты будешь встречать его всё чаще.
Я считаю, что прежде чем вносить в Стандарт, нужно было подумать головой и сделать как следует — то есть добавить эту концепцию (и множество других) в сам язык, а не в библиотеку. Сделать ее атомарной (как массивы, функции и классы), а не реализованной на каких-то навороченных шаблонах и дефайнах. Чтобы была нормальная поддержка компиляторами, нормальные сообщения об ошибках и т.д.
Не знаю что имел в виду топикстартер, но лично у меня претензия не к самой концепции (которая весьма неплоха и весьма полезна), а к тому что все это реализовано средствами, изначально для этого не предназначавшимися. То, что в нормальном языке должно быть потрохами компилятора, в С++ существует в открытом виде в хитрожопых инклудах буста.
Здравствуйте, Anpek, Вы писали:
A>Столкнулся когда-то по работе с любителем буста. Ну это ж просто трындец какой-то. Какой-нить хитрожопый бинд и код запутывается так, что хрен потом разберешься A>Это я только пример привел, таких примеров куча A>И не надо говорить, что я старый пердун и не хочу разбираться в новых технологиях и веяниях
Человек при программировании мыслит паттернами. Причем этих паттернов много, многие из них забываются без надлежащего использования, новые приобретаются. Чистый язык Си, например, достаточно небольшой, и все большинство паттернов можно помнить в одно время. В случае С++ это уже сложнее, обязательно где-то произойдет перекос либо в сторону Си с классами, либо в сторону шаблонизации а-ля boost, либо в сторону ООП с частым использованием множественного наследования и т. п. Конфликт случается, когда ты читаешь код программиста с другим набором таких паттернов. Т. е. разобраться в таком коде ты можешь, но на это уходит больше времени и сил, потому как конструкции не воспринимаются монолитно, а каждую нужно тщательно анализировать.
Кстати, разные code-style также преследуют цель добиться более-менее системы паттернов у программистов, работающих над проектом
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, Qbit86, Вы писали:
Q>>У меня для тебя плохая новость
MTD>У меня для тебя тоже плохая новость. Не в первый раз сталкиваюсь с твоим задором неофита, хотя вроде бы ты не студент. Так вот, по моему мнению, разработчик проходит три этапа: MTD>1. Он еще мало, что знает и пишет так как может MTD>2. Ему кажется, что он уже многое знает и тут начинаются трюки, стремление вместить побольше паттернов, обожествление Буста и Александреску MTD>3. Он действительно знает и умеет, поэтому пишет простой, понятный и расширяемый код
Эффект второй системы, отмеченный еще Бруксом в его книге "Мифический человеко-месяц"
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Qbit86, Вы писали:
A>>Столкнулся когда-то по работе с любителем буста. Ну это ж просто трындец какой-то. Какой-нить хитрожопый бинд и код запутывается так, что хрен потом разберешься
Q>У меня для тебя плохая новость: «хитрожопый бинд» переехал из Буста в Стандарт, теперь ты будешь встречать его всё чаще.
bind можно очень легко "использовать" так, что понадобится три Александреску, чтобы понять, что хотел сказать аффтар.
У нас на всех проектах есть джентельменское соглашение — не рисовать вложенные bind.
Здравствуйте, Qbit86, Вы писали:
Q>Если делать язык с нуля, то, разумеется, функции желательно делать первоклассными объектами, и поддержка частичных применений должна быть естественной.
Кому должна? Зачем ей быть естественной?
Тебя не смущает, что таких языков разработали просто тонны, и они все мало кому нужны почему-то?
Вот, например, всё, что ты хочешь было уже в LISP, который постарше плюсов будет...
И где тот LISP?..
Q>Всё верно. Но с учётом контекста и истории, на текущем этапе эволюции C++ внесение этих вещей в библиотеку, а не ядро — предпочтительнее.
Топик вообще не про это, а про другое.
Почему-то современным инженерам вообще не прививают идею, что писать надо как можно проще, а не как можно сложнее. Про это топик.
То, что ты смог таки одолеть идею биндов говорит о тебе только хорошо и позитивно, только я меня есть маленький совет. Не надо этим хвастаться. Тут есть дофига народу, для кого эта идея вообще никакой трудности не доставила. Для них твои похвальбишки выглядят слегка забавно
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Ops>А тебе не пофиг, как оно реализовано? Я вот очень давно не залезал в исходники ни буста, ни стандартной библиотеки, хотя использую все это каждый день.
А сколько у тебя подчинённых, которые время от времени кодят то, что потом не могут быстро отладить, когда заложенная ими мина таки бахнет?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
L>Думаю, что как Кернинган, так и большинство соучаснегов этого форума под отладкой понимают таки трассировку.
Очень сильно сомневаюсь...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Anpek, Вы писали:
A>Я всю жизнь прогаю на С++, но никак не пойму — зачем писать код, который, чтобы понимать, надо хрен знает сколько знать?
на мой взгляд это проблема образования. Когда готовят инженеров, их натаскивают на то, что бы они могли уверенно применять как можно более наёрнутые навороты, и писать всё более универсальные всемогутеры.
и совсем не учат тому, что программирование, как и любая другая инженерная разработка суть есть деятельность целенаправленная, и целюми обусловленная. И главные цели -- простота поддержки и развития, надёжность изделия, и его могущество у цели, а не красота меганаворотов...
В общем и в целом есть некий перекос, людям дают в головы кучи инструментов для решения очень сложных задач, а задачи им по работе приходят простые, а вот их, как раз, решать ин е учат.
С другой стороны, для большого процента кодеров не нужно какое-то продвинутое образование, вполне достаточно чего-то вроде ПТУ...
В общем, на инженеров учат слишком мало, не успевают или не могут или даже не хотят, потому, что не знают как, развить правильное представление о добре и зле, инженерную интуицию и систему ценностей, а на "просто кодеров" учат слишком много... В результат инженер получает хреновый, потому, что недоучка, а кодер хреновый, потому, что оверквалифицированный. В общем систематический перекос тут есть.
Та же ерунда и в книжках. Все авторы упорно пишут, что не надо всё, что вы тут вычитали тут же во все места всех проектов внедрять, типа это способы улучшить ситуацию в конкретных случаях и сценариях. Но обычно никто этих предисловий не читает, а читают сразу совет номер 146, али вообще сразу в исходники локи лезут... В результате имеем то, что имеем
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Patalog, Вы писали: A>>Столкнулся когда-то по работе с любителем буста. Ну это ж просто трындец какой-то. Какой-нить хитрожопый бинд и код запутывается так, что хрен потом разберешься
P>Лютый батхерт человека, который пытается отлаживать бинд по типу степ-инто, чуствую я.
Неправльно чувствуешь — говорю же — давно было и ничего тогда не дебажил — просто вспомнил впечатление от кода
Впрочем пофиг — кодьте как хотите, мне с вами одну прогу не писать
Здравствуйте, Patalog, Вы писали:
P>Ты имел в виду поанализируй? А в чем там сложоность именно bind'a?
Чем меньше высокоуровневых штук, вносящих свой оверхед, вроде bind'а, тем легче понять, какая машинная инструкция соответствует какому выражению, и в какой регистр что попало, то есть легче понять, что привело к исключению.
Здравствуйте, Qbit86, Вы писали:
Q>Вгоняет в ступор бинд — ну что ж — плохо быть тобой. По возможности избегайте этого.
Я не именно про бинд говорил, ничего там мудреного нету и все с ним понятно. Я говорил, что можно его так применить, что понимание и дебаг кода превращаются в кошмар
И многие еще хвастаются — гляньте как я умею
Здравствуйте, NeoCode, Вы писали:
NC>Я считаю, что прежде чем вносить в Стандарт, нужно было подумать головой и сделать как следует — то есть добавить эту концепцию (и множество других) в сам язык, а не в библиотеку. NC>Сделать ее атомарной (как массивы, функции и классы), а не реализованной на каких-то навороченных шаблонах и дефайнах. Чтобы была нормальная поддержка компиляторами, нормальные сообщения об ошибках и т.д.
Если делать язык с нуля, то, разумеется, функции желательно делать первоклассными объектами, и поддержка частичных применений должна быть естественной.
Но вносить эти изменения конкретно в ядро C++ — это противоречит его духу, дизайну и эволюции. Страуструп не раз говорил, что решение проблем библиотечными средствами предпочтительней.
NC>Не знаю что имел в виду топикстартер, но лично у меня претензия не к самой концепции (которая весьма неплоха и весьма полезна), а к тому что все это реализовано средствами, изначально для этого не предназначавшимися. То, что в нормальном языке должно быть потрохами компилятора, в С++ существует в открытом виде в хитрожопых инклудах буста.
Всё верно. Но с учётом контекста и истории, на текущем этапе эволюции C++ внесение этих вещей в библиотеку, а не ядро — предпочтительнее.
Здравствуйте, NeoCode, Вы писали:
NC>Я считаю, что прежде чем вносить в Стандарт, нужно было подумать головой и сделать как следует — то есть добавить эту концепцию (и множество других) в сам язык, а не в библиотеку. Сделать ее атомарной (как массивы, функции и классы), а не реализованной на каких-то навороченных шаблонах и дефайнах. Чтобы была нормальная поддержка компиляторами, нормальные сообщения об ошибках и т.д.
NC>Не знаю что имел в виду топикстартер, но лично у меня претензия не к самой концепции (которая весьма неплоха и весьма полезна), а к тому что все это реализовано средствами, изначально для этого не предназначавшимися. То, что в нормальном языке должно быть потрохами компилятора, в С++ существует в открытом виде в хитрожопых инклудах буста.
А тебе не пофиг, как оно реализовано? Я вот очень давно не залезал в исходники ни буста, ни стандартной библиотеки, хотя использую все это каждый день.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, NeoCode, Вы писали:
NC>То, что в нормальном языке должно быть потрохами компилятора, в С++ существует в открытом виде в хитрожопых инклудах буста.
Здравствуйте, Qbit86, Вы писали:
Q> Но использование Boost.Bind всё-таки предполагает понимание концепций функций высших порядков и замыканий. Если Boost.Bind вызывает сложности, то это скорее проблема не Буста, а понимания идей, за ним лежащих. Возможно, стоит начать с чего-то попроще, со Scala/C#/F#/Python (и не побоюсь этого слова Haskell). После этого суть «хитрожопых биндов» будет проще разглядеть за вырвиглазным плюсовым синтаксисом.
А еще Boost.Bind создает неимоверное количество проблем при отладке с использованием gdb из консоли, о чем многие вендовые разработчики напрочь забывают.
Здравствуйте, kaa.python, Вы писали:
KP>А еще Boost.Bind создает неимоверное количество проблем при отладке с использованием gdb из консоли, о чем многие вендовые разработчики напрочь забывают.
Юзай GDB >= 7.0 — там есть питоновские постпроцессоры, можно настроить на выкидывание из стектрейса всяких потрохов Boost.Bind, Boost.Test etc
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, kaa.python, Вы писали:
KP>>А еще Boost.Bind создает неимоверное количество проблем при отладке с использованием gdb из консоли, о чем многие вендовые разработчики напрочь забывают.
J>Юзай GDB >= 7.0 — там есть питоновские постпроцессоры, можно настроить на выкидывание из стектрейса всяких потрохов Boost.Bind, Boost.Test etc
Я не уверен что на Mac OS X доступен GDB >= 7.0. Вернее я на 99% что он там не доступен и никогда не будет доступен, ибо GPL 3.0
Да, так и есть:
GNU gdb 6.3.50-20050815 (Apple version gdb-1820) (Sat Jun 16 02:40:11 UTC 2012)
И да, я говорю не только и не столько о стектрейсе, сколько о команде удобстве использования s, n, fin в этом случае.
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, jazzer, Вы писали:
J>>Python — нормальный язык?
MTD>Увы, местами.
Я к тому, что в этом нормальном (увы, местами) языке частичное применение реализовано в виде библиотеки functools.partial.
И никто не матерится, вроде, как здесь.
Я уж не говорю про Хаскель — у него частичное применение по-человечески сделано только для начальных аргументов, а чтоб связать, скажем, только третий аргумент — придется лямбду писать и/или юзать костыли типа flip
Так что Boost.Bind — это совсем не плохой пример реализации этой функциональности.
А то, что она со всеми своими _1 не встроена в язык, позволяет использовать _1 еще в куче мест — в Boost.Phoenix, в Boost.MPL etc
А когда допилят полиформные лямбды — изчезнет, я надеюсь, этот ужас с доступом к членам и оно станет еще читабельнее.
Здравствуйте, kaa.python, Вы писали:
KP>>>А еще Boost.Bind создает неимоверное количество проблем при отладке с использованием gdb из консоли, о чем многие вендовые разработчики напрочь забывают.
J>>Юзай GDB >= 7.0 — там есть питоновские постпроцессоры, можно настроить на выкидывание из стектрейса всяких потрохов Boost.Bind, Boost.Test etc
KP>Я не уверен что на Mac OS X доступен GDB >= 7.0. Вернее я на 99% что он там не доступен и никогда не будет доступен, ибо GPL 3.0 KP>Да, так и есть: KP>
KP>GNU gdb 6.3.50-20050815 (Apple version gdb-1820) (Sat Jun 16 02:40:11 UTC 2012)
KP>
Мак — суксь, я всегда это знал
KP>И да, я говорю не только и не столько о стектрейсе, сколько о команде удобстве использования s, n, fin в этом случае.
это тоже, я уверен, можно перенастроить, чтоб он корректно проваливался/вылетал, пропуская мусор — в GDB же все команды переопределить можно, ЕМНИП.
Здравствуйте, landerhigh, Вы писали:
L>Но вот что совершенно точно, та это то, что отладка — очень медленный, малоэффективный и совершенно не поддающийся автоматизации процесс.
Коллега, с этим спорить невозможно.
L>Поэтому я, например, пишу для своего кода юнит-тесты.
Я тоже пишу, но они иногда не работают, а иногда работают, но не работает программа (почему вопрос для отдельной темы).
L>Отладкой собственного кода приходится заниматься ровно в двух случаях.
Здесь надо уточнить, что подразумевается под отладкой, если трассировка в отладчике, то я этим занимаюсь от силы раз в пол года, но с другой стороны я часто медитирую над логами — это отладка?
Здравствуйте, Anpek, Вы писали:
A>Во почитал тут про просьбу накидать извратов в С++ A>И встал вопрос — зачем все это? A>Я всю жизнь прогаю на С++, но никак не пойму — зачем писать код, который, чтобы понимать, надо хрен знает сколько знать?
A>Столкнулся когда-то по работе с любителем буста. Ну это ж просто трындец какой-то. Какой-нить хитрожопый бинд и код запутывается так, что хрен потом разберешься A>Это я только пример привел, таких примеров куча A>И не надо говорить, что я старый пердун и не хочу разбираться в новых технологиях и веяниях
A>С++ — это всего лишь молоток, который дан вам в руки. Когда люди начинают хвастаться, что умеют делать молотком массаж простаты с одновременным пломбированием зубов — ну что ж — флаг вам в руки
А я с буста перешел на netbsd. Тоже самое сделал jmmv. А еще мы немного Lua балуемся :-;
Здравствуйте, jazzer, Вы писали:
J>Я уж не говорю про Хаскель — у него частичное применение по-человечески сделано только для начальных аргументов, а чтоб связать, скажем, только третий аргумент — придется лямбду писать и/или юзать костыли типа flip
J>Так что Boost.Bind — это совсем не плохой пример реализации этой функциональности.
Ну, flip — это для тех случаев, когда нельзя использовать сечения (x `foo`) / (`foo` x).
А если бы их можно было использовать — там получился бы такой адский инфиксный ад со скобками.
Так что вся эта игра в тацитную нотацию — это даже не от безысходности (как в APL/J/K), а больше от баловства (имхо). Не зря же хаскельщики один из комбинаторов так и называют: "оператор сиськи" (.)(.)
Местоимения хороши, когда они в язык встроены (хотя бы с помощью макросистемы, как в lisp/th/n). Иначе всякие заморочки вылезают, которые надо компенсировать многословностью (трёхэтажные bind'ы).
А так, велика ли разница написать \x y -> f x 123 y против f(_,123,_) ?
Здравствуйте, NeoCode, Вы писали:
Q>>У меня для тебя плохая новость: «хитрожопый бинд» переехал из Буста в Стандарт, теперь ты будешь встречать его всё чаще.
NC>Я считаю, что прежде чем вносить в Стандарт, нужно было подумать головой и сделать как следует — то есть добавить эту концепцию (и множество других) в сам язык, а не в библиотеку. Сделать ее атомарной (как массивы, функции и классы), а не реализованной на каких-то навороченных шаблонах и дефайнах. Чтобы была нормальная поддержка компиляторами, нормальные сообщения об ошибках и т.д.
Дык лямбды жеж...
NC>Не знаю что имел в виду топикстартер, но лично у меня претензия не к самой концепции (которая весьма неплоха и весьма полезна), а к тому что все это реализовано средствами, изначально для этого не предназначавшимися. То, что в нормальном языке должно быть потрохами компилятора, в С++ существует в открытом виде в хитрожопых инклудах буста.
Дык легаси...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, landerhigh, Вы писали:
L>bind можно очень легко "использовать" так, что понадобится три Александреску, чтобы понять, что хотел сказать аффтар.
Всё ещё хуже. Часто у некоторых аффторов полёт мысли достигает таких высот абстракции, что они и сами не в курсе, что же они хотели сказать...
А работает всё, в результате, по каким-то случайным причинам и не всегда, а когда повезёт, соответственно
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, kaa.python, Вы писали:
J>>Юзай GDB >= 7.0 — там есть питоновские постпроцессоры, можно настроить на выкидывание из стектрейса всяких потрохов Boost.Bind, Boost.Test etc KP>Я не уверен что на Mac OS X доступен GDB >= 7.0. Вернее я на 99% что он там не доступен и никогда не будет доступен, ибо GPL 3.0
Прекрасно он там доступен, просто руками надо собрать. Даже с XCode можно интегрировать при желании (а ещё с IntelliJ AppCode).
KP>И да, я говорю не только и не столько о стектрейсе, сколько о команде удобстве использования s, n, fin в этом случае.
Helper'ы рулят.
Здравствуйте, Cyberax, Вы писали:
C>Прекрасно он там доступен, просто руками надо собрать. Даже с XCode можно интегрировать при желании (а ещё с IntelliJ AppCode).
Да, пожалуй ты прав, в портах лежит 7.5. Слона то я и не приметил
KP>>И да, я говорю не только и не столько о стектрейсе, сколько о команде удобстве использования s, n, fin в этом случае. C>Helper'ы рулят.
Здравствуйте, kaa.python, Вы писали:
KP>Я не уверен что на Mac OS X доступен GDB >= 7.0. Вернее я на 99% что он там не доступен и никогда не будет доступен, ибо GPL 3.0 KP>Да, так и есть: KP>
KP>GNU gdb 6.3.50-20050815 (Apple version gdb-1820) (Sat Jun 16 02:40:11 UTC 2012)
KP>
Так уж и никогда?
$ gdb --version
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin12.2.0".
Здравствуйте, kaa.python, Вы писали:
KP>>>И да, я говорю не только и не столько о стектрейсе, сколько о команде удобстве использования s, n, fin в этом случае. C>>Helper'ы рулят. KP>Кто рулит?
Скрипты для gdb. Существенно облегчают жизню.
Здравствуйте, Erop, Вы писали:
Q>>У меня для тебя плохая новость: «хитрожопый бинд» переехал из Буста в Стандарт, теперь ты будешь встречать его всё чаще. E>Зачем бы это, при живых-то лямбдах?
Здравствуйте, Erop, Вы писали:
E>и совсем не учат тому, что программирование, как и любая другая инженерная разработка суть есть деятельность целенаправленная, и целюми обусловленная. И главные цели -- простота поддержки и развития, надёжность изделия, и его могущество у цели, а не красота меганаворотов...
Проблема в том, что процитированное — это Священный Грааль программирования. Обеспечение "поддерживаемости и расширяемости" часто достигается введением избыточности кода, плюс чуть менее чем всегда направление этого развития представляет из себя понятие настолько абстрактное, что принять на основании этих данных какие-либо технические решения невозможно — можно лишь говорить о том, насколько те возможности расширения, которые в код закладывают, совпадут с реальностью. И кто бы тут что не говорил, здесь всегда есть вероятность "промаха". Поэтому-то придумали 100500 методик предвосхищения этих требований, но по сути все они являются предположениями с той или иной достоверностью.
В российской высшей школе прививают системный подход к решению проблем, то есть учат решать не конкретную проблему, а сразу целый класс проблем. Это хорошо работает в "классическом" инжениринге, где в конце концов имеется конечная цель, но в случае программирования конечная цель часто не определена вообще либо определена предельно размыто — отсюда оверенжиниринг, чтобы предусмотреть максимальное количество вариантов развития.
Здравствуйте, koandrew, Вы писали:
K>Проблема в том, что процитированное — это Священный Грааль программирования. Обеспечение "поддерживаемости и расширяемости" часто достигается введением избыточности кода,
Не совсем так. Некоторые не особо сильно опытные инженеры, часто пытаются достичь поддерживаемости и расширяемости за счёт избыточности кода, но неудачно.
А так да, для поддерживаемости доп. код, конечно же нужен, например код системы логгирования
K>плюс чуть менее чем всегда направление этого развития представляет из себя понятие настолько абстрактное, что принять на основании этих данных какие-либо технические решения невозможно — можно лишь говорить о том, насколько те возможности расширения, которые в код закладывают, совпадут с реальностью.
И тут тоже можно просто из денег исходить, например, и не платить за то, за что тебе пока не надо... Но такому подходу не учат.
K>И кто бы тут что не говорил, здесь всегда есть вероятность "промаха". Поэтому-то придумали 100500 методик предвосхищения этих требований, но по сути все они являются предположениями с той или иной достоверностью.
Ну в "обычном инженерном искусстве" есть всё примерно тоже самое, например ТРИЗ и АРИЗ... Другое дело, что там и тут промахи случаются с разной частотой.
K>В российской высшей школе прививают системный подход к решению проблем, то есть учат решать не конкретную проблему, а сразу целый класс проблем. Это хорошо работает в "классическом" инжениринге, где в конце концов имеется конечная цель, но в случае программирования конечная цель часто не определена вообще либо определена предельно размыто — отсюда оверенжиниринг, чтобы предусмотреть максимальное количество вариантов развития.
В коммерческом ПО конечная цель конкретна, как нигде, и эта цель -- профит
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Patalog, Вы писали:
P>А меня все время мучает другой вопрос — нахрена писать код, в котором конечно ничего из знания языка кроме scanf
В идеале scanf -- тоже переусложнение кода
P>знать не надо, но банальный парсер который на спирите пишется влет и занимает 50 строк вместе с вменяемой обработкой ошибок из коробки, занимает в конечном итоге сторок 500 и не падает только на тшательно подобранных входных данных?
Я не очень понимаю, что ты и имеешь в виду под "парсер", но если чувак не может написать и отладить программу в 500 строк, то он просто не умеет программировать, и на спирите кодить ему тем более доверять не надо, бо потом не отладишь никогда...
Ну а что касается твоего вопроса "зачем писать простой код в 500 строк вместо сложного в 50?" ответ очень прост. Иногда надо первое, а иногда второе.
Второе -- чаще надо в write only коде. Потому, что при нормально программировании само по себе кодирование занимает не так много времени, поэтому важнее где проще искать и править ошибки, а не где меньше строк кода. Это, конечно, если ты шибки ишешь методом приложения головы, а не методом тыка пальца, так как если второе, то чем короче код, тем метод тыка пальца эффективнее
A>>Столкнулся когда-то по работе с любителем буста. Ну это ж просто трындец какой-то. Какой-нить хитрожопый бинд и код запутывается так, что хрен потом разберешься
P>Лютый батхерт человека, который пытается отлаживать бинд по типу степ-инто, чуствую я.
А ты уверен, что дело в незнании биндов ТСом, а не в том, что "любитель буста" был не в состоянии написать и отладить парсер в 500 строк?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
[]
P>>Лютый батхерт человека, который пытается отлаживать бинд по типу степ-инто, чуствую я.
AG>Фиг бы с пошаговой отладкой, ты анонимные креш-дампы подебажь
Ты имел в виду поанализируй? А в чем там сложоность именно bind'a?
Начал писать развернутый ответ, но наткнувшись на
>Это, конечно, если ты шибки ишешь методом приложения головы, а не методом тыка пальца, так как если второе, то чем короче код, тем метод тыка пальца эффективнее
скажу проще — иди в опу, ты ведь именно этого добиваешься.
Здравствуйте, Patalog, Вы писали:
P>Начал писать развернутый ответ, но наткнувшись на
Перевожу на русский: "Начал писать развернутый ответ, но понял, что по существу-то сказать нечего"
>>Это, конечно, если ты шибки ишешь методом приложения головы, а не методом тыка пальца, так как если второе, то чем короче код, тем метод тыка пальца эффективнее
P>скажу проще — иди в опу, ты ведь именно этого добиваешься.
Тебя с твоим вбросом про scanf вообще-то никто не звал
Но, кстати, я тебя не оскорблял, а наоборот, предполагал, что ты ищешь ошибки не методом тыка пальцем, а как-то иначе. Прости, что ошибся...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
[]
P>>Ты имел в виду поанализируй? А в чем там сложоность именно bind'a?
AG>Чем меньше высокоуровневых штук, вносящих свой оверхед, вроде bind'а, тем легче понять, какая машинная инструкция соответствует какому выражению, и в какой регистр что попало, то есть легче понять, что привело к исключению.
т.е. указатели на функции (не говоря уже про функторы) тоже казнить, как излишне "высокоуровневые штуки"?
Здравствуйте, Patalog, Вы писали:
P>т.е. указатели на функции (не говоря уже про функторы) тоже казнить, как излишне "высокоуровневые штуки"?
Казнить максимализм.
Можно написать функцию, принимающую функтор и передать туда boost::bind.
Но всё же для продакшн кода может быть полезно упростить это дело до функции, принимающей указатель на интерфейс, и передачи реализации, пусть ценой некоторой многословности.
Здравствуйте, Patalog, Вы писали:
P>А меня все время мучает другой вопрос — нахрена писать код, в котором конечно ничего из знания языка кроме scanf знать не надо, но банальный парсер который на спирите пишется влет и занимает 50 строк вместе с вменяемой обработкой ошибок из коробки, занимает в конечном итоге сторок 500 и не падает только на тшательно подобранных входных данных?
Перекуём баги на фичи!
