Здравствуйте, 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. Существенно облегчают жизню.
Здравствуйте, Anpek, Вы писали:
A>Я всю жизнь прогаю на С++, но никак не пойму — зачем писать код, который, чтобы понимать, надо хрен знает сколько знать?
на мой взгляд это проблема образования. Когда готовят инженеров, их натаскивают на то, что бы они могли уверенно применять как можно более наёрнутые навороты, и писать всё более универсальные всемогутеры.
и совсем не учат тому, что программирование, как и любая другая инженерная разработка суть есть деятельность целенаправленная, и целюми обусловленная. И главные цели -- простота поддержки и развития, надёжность изделия, и его могущество у цели, а не красота меганаворотов...
В общем и в целом есть некий перекос, людям дают в головы кучи инструментов для решения очень сложных задач, а задачи им по работе приходят простые, а вот их, как раз, решать ин е учат.
С другой стороны, для большого процента кодеров не нужно какое-то продвинутое образование, вполне достаточно чего-то вроде ПТУ...
В общем, на инженеров учат слишком мало, не успевают или не могут или даже не хотят, потому, что не знают как, развить правильное представление о добре и зле, инженерную интуицию и систему ценностей, а на "просто кодеров" учат слишком много... В результат инженер получает хреновый, потому, что недоучка, а кодер хреновый, потому, что оверквалифицированный. В общем систематический перекос тут есть.
Та же ерунда и в книжках. Все авторы упорно пишут, что не надо всё, что вы тут вычитали тут же во все места всех проектов внедрять, типа это способы улучшить ситуацию в конкретных случаях и сценариях. Но обычно никто этих предисловий не читает, а читают сразу совет номер 146, али вообще сразу в исходники локи лезут... В результате имеем то, что имеем
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
Q>>У меня для тебя плохая новость: «хитрожопый бинд» переехал из Буста в Стандарт, теперь ты будешь встречать его всё чаще. E>Зачем бы это, при живых-то лямбдах?
хъ
A>Я всю жизнь прогаю на С++, но никак не пойму — зачем писать код, который, чтобы понимать, надо хрен знает сколько знать?
А меня все время мучает другой вопрос — нахрена писать код, в котором конечно ничего из знания языка кроме scanf знать не надо, но банальный парсер который на спирите пишется влет и занимает 50 строк вместе с вменяемой обработкой ошибок из коробки, занимает в конечном итоге сторок 500 и не падает только на тшательно подобранных входных данных?
A>Столкнулся когда-то по работе с любителем буста. Ну это ж просто трындец какой-то. Какой-нить хитрожопый бинд и код запутывается так, что хрен потом разберешься
Лютый батхерт человека, который пытается отлаживать бинд по типу степ-инто, чуствую я.
Здравствуйте, Patalog, Вы писали: A>>Столкнулся когда-то по работе с любителем буста. Ну это ж просто трындец какой-то. Какой-нить хитрожопый бинд и код запутывается так, что хрен потом разберешься
P>Лютый батхерт человека, который пытается отлаживать бинд по типу степ-инто, чуствую я.
Неправльно чувствуешь — говорю же — давно было и ничего тогда не дебажил — просто вспомнил впечатление от кода
Впрочем пофиг — кодьте как хотите, мне с вами одну прогу не писать
Здравствуйте, 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 вообще-то никто не звал
Но, кстати, я тебя не оскорблял, а наоборот, предполагал, что ты ищешь ошибки не методом тыка пальцем, а как-то иначе. Прости, что ошибся...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Patalog, Вы писали:
P>Ты имел в виду поанализируй? А в чем там сложоность именно bind'a?
Чем меньше высокоуровневых штук, вносящих свой оверхед, вроде bind'а, тем легче понять, какая машинная инструкция соответствует какому выражению, и в какой регистр что попало, то есть легче понять, что привело к исключению.
[]
P>>Ты имел в виду поанализируй? А в чем там сложоность именно bind'a?
AG>Чем меньше высокоуровневых штук, вносящих свой оверхед, вроде bind'а, тем легче понять, какая машинная инструкция соответствует какому выражению, и в какой регистр что попало, то есть легче понять, что привело к исключению.
т.е. указатели на функции (не говоря уже про функторы) тоже казнить, как излишне "высокоуровневые штуки"?
Здравствуйте, Patalog, Вы писали:
P>т.е. указатели на функции (не говоря уже про функторы) тоже казнить, как излишне "высокоуровневые штуки"?
Казнить максимализм.
Можно написать функцию, принимающую функтор и передать туда boost::bind.
Но всё же для продакшн кода может быть полезно упростить это дело до функции, принимающей указатель на интерфейс, и передачи реализации, пусть ценой некоторой многословности.
Здравствуйте, Patalog, Вы писали:
P>А меня все время мучает другой вопрос — нахрена писать код, в котором конечно ничего из знания языка кроме scanf знать не надо, но банальный парсер который на спирите пишется влет и занимает 50 строк вместе с вменяемой обработкой ошибок из коробки, занимает в конечном итоге сторок 500 и не падает только на тшательно подобранных входных данных?
