LINUX.ORG.RU

Есть ли современный аналог DDD?

 , , , ,


2

4

Интересует возможность наглядно отображать структуры данных при отладке: http://www.cs.angelo.edu/~mmotl/2305/manual/ddd/html/PICS/ddd-layout.png https://bcaptain.files.wordpress.com/2013/06/ddd.png

Может в каких-то попсовых IDE что-то подобное запилили.

Языки: Си, C++. Всякие хаскели и проч - не интересует.

★★★★★

Последнее исправление: SZT (всего исправлений: 1)

Скорее всего в Эклипсе должно что-то подобное быть. Но обычным людям это не актуально.

cvv ★★★★★
()
Ответ на: комментарий от cvv

Ну я смотрел на эклипс, и такой вот наглядной визуализации для деревьев и связных списков я не нашел.

SZT ★★★★★
() автор топика
Ответ на: комментарий от Kroz

Ну про генераторы всяких UML диаграмм, call graph и проч. из кода я знаю, недавно кстати https://www.sourcetrail.com/ заопенсорсили.

Но нет, мне именно отладка нужна.

SZT ★★★★★
() автор топика
Ответ на: комментарий от beastie

Ну например тем, что он не обновлялся с 2009/02/11 и глючит.

SZT ★★★★★
() автор топика

Нормальный пацан printf’ами отлаживается. Если печатать некуда, то моргать светодиодами ещё можно, или пин какой дёргать, если светодиода нету.

mv ★★★★★
()
Ответ на: комментарий от mv

Шаблоны на C++ примерно невозможно отладить печатанием, потому что во первых, в C++ не можно печатать типы, а во вторых любой чих под этими шаблонами влечёт пересборку хреновой тучи кода на пол-дня.

d_a ★★★★★
()
Ответ на: комментарий от d_a

Шаблоны на C++ примерно невозможно отладить печатанием

Возможно. Их как раз-таки по иному отладить нельзя. Или ты покажешь как можно?

потому что во первых, в C++ не можно печатать типы

Не знаю о каком С++ ты говоришь, но в С++ в этой реальности можно печатать типы.

а во вторых любой чих под этими шаблонами влечёт пересборку хреновой тучи кода на пол-дня.

А это уже проблема рукожопости того, кто тебе так организовал проект.

xiomar_georgios
()
Ответ на: комментарий от xiomar_georgios

Мне кажется ты не догоняешь. Я говорю о случаях, когда вся кодовая база шаблонная by design, кроме самых простых частей. Например таких. И возможность отладки без правки кода под шаблонами здесь экономит буквально дни на пересборке этого дерьма.

d_a ★★★★★
()
Ответ на: комментарий от d_a

Шаблоны на C++ примерно невозможно отладить печатанием, потому что во первых, в C++ не можно печатать типы, а во вторых любой чих под этими шаблонами влечёт пересборку хреновой тучи кода на пол-дня.

Какой гомноязык!

mv ★★★★★
()
Ответ на: комментарий от mv

Мерси за комплиман, но кажется он ещё хуже.

d_a ★★★★★
()
Ответ на: комментарий от d_a

Мне кажется ты не догоняешь.

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

Я говорю о случаях, когда вся кодовая база шаблонная by design, кроме самых простых частей.

Ты говоришь глупости. Выдавая проблемы организации кода за проблемы шаблонов. К тому же, как-то быстро ты поменял тему. И забыл показать то, как ты будешь отлаживать эти шаблоны без пересборки.

Например таких. И возможность отладки без правки кода под шаблонами здесь экономит буквально дни на пересборке этого дерьма.

Это говно не имеет никакого отношения к С++, нормальной организации кода, шаблонам и прочим базвордам.

Поэтому повторю. Не путай проблемы вызванным говном и проблемы вызванные шаблонами. И не выдавай свои решения для работы с мусорным легаси-говном на другом языке за решения по работе с этим языком и шаблонами.

xiomar_georgios
()
Ответ на: комментарий от mv

Показывай. Я даже не буду просить много - слишком быстро всё закончится. Просто покажи аналог того самого дерьма с теми же потребительскими свойствами, но без указанных выше проблем. Я знаю, ты сможешь.

xiomar_georgios
()
Ответ на: комментарий от menangen

Не покажет, не волнуйся. А если каким-то чудом и покажет, то это лишь заранее слабый случай. Далее пойдёт что-то серьёзное. Но до этого не дойдёт, повторю.

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

К тому же эта методичка нарушает тезисы эксперта выше. Отлаживается кодоген ещё хуже, нежели упомянутое выше псевдошаблонное псведоc++ говно.

Но опять же, на это так же есть своя методичка. У экспертов в пхп никогда никаких проблем нет. У них есть секретные инструменты, которые решают все задачи. Правда показать они их не могут. Но то неважно.

xiomar_georgios
()

Гуишных оберток gdb для линукса как грязи, любая идешка их включает: qtcreator, eclipse, netbeans, clion и т.д. Все они имеют опцию приаттачится к уже запущенному процессу или самостоятельно его запустить. Т.е. не нужно в них добавлять проект, зачастую есть возможность запустить стороннюю уже собранную чем-то другим программу и начать ее отлаживать во встроенном отладчике.

По поводу визуализации всяких векторов и мап — это вопрос отдельный. Все эти идешки так или иначе это умеют делать. Но, иногда, у них эта визуализация не работает из коробки, т.к. зависит от онкретного бинарного представления текущей libstdc++ или еще каких системных либ. В таких случаях нужно гуглить решения для конкретных ситуаций.

Я пользуюсь clion, там все неплохо сразу работает из коробки. Но он платный и не всем нравится.

anonymous
()
Ответ на: комментарий от xiomar_georgios

Показывай. Я даже не буду просить много - слишком быстро всё закончится. Просто покажи аналог того самого дерьма с теми же потребительскими свойствами, но без указанных выше проблем. Я знаю, ты сможешь.

У меня охват погроммистский небольшой. В плане «мета» общелисп от плюсов мокрого места не оставляет. Его же и отлаживать проще, гораздо. И софт не глючит. Сишечку тоже проще гораздо отлаживать, там 90% всех косяков - из-за просранной памяти или неправильно разведённые блокировки, одно из двух.

mv ★★★★★
()
Ответ на: комментарий от xiomar_georgios

Покажи пример.

Ну что тут можно показать? Макрос в CL - это обычный общелисповый код, который на вход получает форму и на выходе выдаёт форму. Среда гоняет файл, пока все вложенные макросы окончательно не развернутся. Помножь всё это на гомоиконность лиспа, и через пару-тройку лет у общелисповика написание софта превращается в написание кучи мелких eDSL.

Только чтобы после карцера C++ понять всю свободу CL, нужно, чтобы в голове натурально щёлкнуло.

mv ★★★★★
()
Ответ на: комментарий от mv

Ну что тут можно показать?

Ну как что - применение. Если ты знаешь плюсы одного подхода и минусы другого, то ты без проблем сможешь придумать пример в котором разница будет очевидно.

Макрос в CL - это обычный общелисповый код, который на вход получает форму и на выходе выдаёт форму. Среда гоняет файл, пока все вложенные макросы окончательно не развернутся. Помножь всё это на гомоиконность лиспа, и через пару-тройку лет у общелисповика написание софта превращается в написание кучи мелких eDSL.

Зачем ты мне что-то рассказываешь про свою скриптуху? Это примитивная херня. К тому же, ты похоже забыл методичку. Но я помню - за альтернативу С++ канает только кодоген. Кодоген с таргетом си(или подобным). В противном случае твоя скриптуха - это совсем ясли.

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

Ты находишься на том же уровне, что и веб-адепт с его жсончиком и рассказами как он там месит его структуру. Только вот и ты он забывают об одном обстоятельстве. Месить что-то можно лишь потому, что это и и то структурно примитивные рекурсивные два/три правила.

Структура же нормального языка, как и структура любой состоятельной организации памяти - куда сложнее. И все твои маня-рассуждения уже идут мимо.

Поэтому я и задал тебе простой вопрос - покажи. А ты не показал, но при этом слился с темы и сменил методичку в полёте.

Только чтобы после карцера C++ понять всю свободу CL, нужно, чтобы в голове натурально щёлкнуло.

Ты ничего не знаешь о С++ и все твои рассуждения можно свести к карцеру собственной состоятельности, вернее её отсутствия.

Приведи пример. Покажи предмет, а не какие-то мантры. Хотя как только ты его покажешь - мантры кончатся.

xiomar_georgios
()
Ответ на: комментарий от mv

Ухх, сейчас тебе царь наверно расскажет про птушников, скриптушню, сектантов, что в C++ самая развитая система типов в принципе и ничего лучше не придумали. Странно что он так долго держится. Советую посмотреть удаленные в теме В чем отличие процедурного программирования от функционального? (ник sparrowjarell)

SZT ★★★★★
() автор топика

Если структуры рисовать,

то да, как и выше сказано, gdbgui. А так-то, чтоб ни printf’ами и не пины дёргать со светодиодами, если есть возможность, то я за «чистый» gdb. Он при необходимости и скриптуется на том же пистончике вполне неплохо, а так же в Вашем хомяке есть файлец .gdbinit, откуда команды исполняются при старте gdb (прстейший пример – перекрасим приглашение gdb$ в красный – set prompt \033[01;31mgdb$ \033[0m). Можно вполне нехило автоматизироваться. В этом встроенном «язычке макросов» есть даже циклы, так что нет необходимости повторять какие-либо стандартные действия, специфичные для отлаживаемого приложения.

С другой стороны, команды gdb можно заскриптовать и через ex или (как вариант с ex) через batch-mode. т.е., создать скрипт.gdb, например и, далее, gdb –batch –command=скрипт.gdb –args ./отлаживаемое_приложение [аргументы комм. строки приложения]. А в «скрипт.gdb» указать что-то типа:

set width 0
set height 0
set verbose off
b main
start
commands 1
  print argc
  backtrace   # Да, backtrace на main(), после вывода argc.
              # Чисто примера скрипта ради.
  continue
end

Примерчик, конечно, «так себе», но я просто чисто понимания ради накидал. Мощная вещь этот наш gdb…

Moisha_Liberman ★★
()
Ответ на: комментарий от menangen

Если честно...

То я как-то не особо тяготею к LLVM-стеку et al. Оно не совсем понятно в принципе нафиг нужно. Хотя, да… новое, модное, блестящее, стильное, модное, молодёжное, бородатое, педова… =))) Так, последнее это явно не сюда… =)))

Зачем? GDB весьма неплох же. =) А так я лично (за всех говорить не буду) не вижу особого смысла в смене технологического стека. Да, в шланг и связанные технологии сейчас вливают бабло. Но сколько это будет продолжаться ни кто не знает. Чем это кончится тоже никто не знает. А тот же gcc вырос не благодаря, а вопреки. И доказал свою жизнеспособность. Тут бы сказать по обыкновению «лучше бы gcc пилили, чтоб фрагментацию не множить».

Да, по временам gcc колупается дольше, но так же по временам генерирует более быстрый код (тестировано на разных платформах). Раз на раз не приходится. Да, тут особо нового ничего не придумаешь. А что нужно придумывать? Если про gcc extensions, то они великолепны. Да, в шланге «более понятные сообщения об ошибках». Но если погроммист не вкуривает что ему хочет сказать компиль, то тут уже вопрос – а погроммист вообще понимает что и на кой пень он делает? =)

Ну вот… Как-то вот так. В общем и целом. А так-то я совсем не против clang, lldb и вот это вот всего… =)

Moisha_Liberman ★★
()
Ответ на: Если честно... от Moisha_Liberman

Не, я в контексте lldb vs gdb. Думал, может, у тебя есть какие-то предпочтения на основе опыта и с тем, и с тем

menangen ★★★★★
()
Ответ на: комментарий от menangen

В общем и целом я не вижу смысла.

Думал, может, у тебя есть какие-то предпочтения на основе опыта и с тем, и с тем

Я же не зря сказал что не вижу смысла в смене технологического стека и перечислил почему именно. Профита особого не вижу. =)

Если именно и чисто про lldb vs. gdb, то разница по большому счёту только в одном – в принадлежности пакета и лицензии. Gdb это часть проекта GNU, а lldb это часть LLVM suite. Особо нового с технологической точки зрения lldb ничего не привнёс, отладчик и есть отладчик. Правда, в GDB можно было остановить один поток исполнения по брек-пойнту, а в то время, когда я активно этим интересовался, в lldb этого было нельзя сделать. Сейчас, вроде, починили, но это смотреть надо.

Ну и скриптовый API в lldb явно выражен и заточен под использование с пистончиком. Хотя, говорят, вроде и на lua можно, но я лично не пробовал. Мне и скриптового языка gdb выше крыши.

UPD. Да, про Scripting API в lldb – https://lldb.llvm.org/use/python.html Прикольно, да… Но тесты напиши, код напиши, теперь вот ещё и для отладчика скрипт напиши чтобы отладиться на ещё одном языке… Вот так и живём. Хорошо. Весело. =)

Moisha_Liberman ★★
()
Последнее исправление: Moisha_Liberman (всего исправлений: 1)
Ответ на: комментарий от menangen

Это я так... Издаля смотрел.

Да там ещё и новые языки же под LLVM типа swift/crystal/D. А там свой дебаг процесс, и свои форки lldb 😅вот где веселье начинается

Палочкой потыкал и задумался – зачем оно мне нужно. Хотя, оно понятно что всё… «совершенствуется» и даже вон, Царь… Из Царя С в Царя С++ превратился… =)))

Moisha_Liberman ★★
()
Ответ на: В общем и целом я не вижу смысла. от Moisha_Liberman

Правда, в GDB можно было остановить один поток исполнения по брек-пойнту, а в то время, когда я активно этим интересовался, в lldb этого было нельзя сделать. Сейчас, вроде, починили, но это смотреть надо.

В GDB есть одна малоизвестная фича - reverse debugging https://sourceware.org/gdb/wiki/ReverseDebug - и в LLDB на данный момент такого нет

SZT ★★★★★
() автор топика
Ответ на: Это я так... Издаля смотрел. от Moisha_Liberman

и даже вон, Царь… Из Царя С в Царя С++ превратился… =)))

Ума и адекватности ему от этого не прибавилось, по-моему только убавилось, взять например его недавнее утверждение:

Система типов у С++ самая развитая в мире в принципе. Всё остальное - это не полноценные языки и там попросту на уровень типов прикрутили ещё один язык.

Я даже не знаю как такую чушь комментировать.

SZT ★★★★★
() автор топика
Ответ на: комментарий от SZT

А это и не удивительно.

в LLDB на данный момент такого нет

Да. Если угодно, то «техническая зрелость» проекта LLVM в общем и целом, равно как и отдельных его частей не такова, чтобы обращать внимание на такие… «тонкие» вещи, как process record, на котором основана возможность реверсной отладки в именно и чисто Linux. Возможно, потом… когда-нибудь и дорастут до этого. Пока Apple решает свои задачи и им пофиг Linux. Поэтому я и опасаюсь что пока бабло вливают, рост и движуха есть. Перестанут? А вот тут бабка надвое сказала что будет. С gcc по крайней мере всё и так ясно. Есть и работает.

Moisha_Liberman ★★
()
Ответ на: комментарий от SZT

Да никак ненадо. =)

Царь сам по себе, видимо мужик хороший. Но барагозить любит видимо от того, что ему заняться по временам особо нечем. Вот и… «несёт свет Знания». =)))

Я лично воспринимаю его как данность. Мы же именно за это лорчик и любим таким, каков он есть. Да, даже вместе с Царём (пылью запартной). =)))

Moisha_Liberman ★★
()
Последнее исправление: Moisha_Liberman (всего исправлений: 1)
Ответ на: комментарий от SZT

Я даже не знаю как такую чушь комментировать.

Это так мило. Адепт впаривал какое-то говно, далее я ответил базовым тезисом. И всё - адепт поплыл. Началось завывание какие-то сектантских мантр про «в моей агитке этого нет». Началась аргументация вида «ну раз в моей сектантской агитке этого нет - это не так».

На этом потуги закончились. Теперь адепт бегает и пастит это везде в поисках утешения. Что найдётся другой сектант, который с ним солидаризируется.

Ну дак что, у тебя будет какой-то ответ на это? Или и дальше будешь бегать как клоун ссылаясь на сектантские мантры?

xiomar_georgios
()
Ответ на: комментарий от xiomar_georgios

Адепт впаривал какое-то говно, далее я ответил базовым тезисом.

Опять тебе адепты какие-то мерещатся...

Ну ОК давай проведем эксперимент, давай я еще более долбанутый тезис выдвину на основе твоего:

Система типов у С самая развитая в мире в принципе. Всё остальное - это не полноценные языки и там попросту на уровень типов прикрутили ещё один язык.

Как ты будешь этот тезис опровергать? Если ты скажешь что вот язык C++ есть - там система типов более развитая - я тебе отвечу что это просто на уровень типов Си прикрутили еще один язык.

SZT ★★★★★
() автор топика
Последнее исправление: SZT (всего исправлений: 1)
Ответ на: комментарий от SZT

Система типов у С самая развитая в мире в принципе. Всё остальное - это не полноценные языки и там попросту на уровень типов прикрутили ещё один язык.

Показывай, где в С++ вместо системы типов отдельный язык. Ну и эквивалент этого на си в студию: https://godbolt.org/z/ceUt_F

Если ты скажешь что вот язык C++ есть - там система типов более развитая - я тебе отвечу что это просто на уровень типов Си прикрутили еще один язык.

Ты это не скажешь - ты это пойдёшь доказывать.

xiomar_georgios
()
Ответ на: комментарий от SZT

Быстро же ты обделался. В этом и разница - ты сектант. А зачем - всё просто - это контр-пример твоему тезису. Если твоя система типов сильнее - она может больше. Вот я привёл пример того, что может одна система типов. Далее ты должен на это ответить.

xiomar_georgios
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.