среда, 10 апреля 2013 г.

Чего мне не хватает в Delphi по сравнению с xCode

Так это НОРМАЛЬНОГО СТАТИЧЕСКОГО анализатора.

Или может быть я всё проспал и такое уже есть?

Ну и ДИНАМИЧЕСКОГО - тоже. Про AQTime etc - я знаю, но в xCode - явно лучше. Он утечки показывает - ПРАКТИЧЕСКИ с точностью до строчки.

Понимаете - я был совсем "чайник" в xCode (хотя когда читал мануал - я СМЕЯЛСЯ - "ну что вы мне про подсчёт ссылок рассказываете - я же "гуру" в них, я же - "сам всё это придумал")... Но когда я запустил СТАТИЧЕСКИЙ анализатор кода - Я БЫЛ ПОРАЖЁН.. Он мне показал ТАКИЕ места, о которых бы я никогда бы не подумал..

А уж когда запустил ДИНАМИЧЕСКИЙ (Memory Leaks) - я был поражён ещё БОЛЬШЕ...

Это ТОЛЬКО у меня такие руки кривые? Или такие инструменты всё же востребованы на рынке?

Рассказать кстати - как я считаю количество неосвобождённых объектов в Delphi? Или неинтересно?

23 комментария:

  1. >как я считаю количество неосвобождённых объектов в Delphi?
    fastmm умеет сразу из коробки - ReportMemoryLeaksOnShutdown.

    Статический анализатор - видел о нем упоминание в форумах, название не помню, коммерческий и стоит прилично.

    Это не статический анализ но все таки:
    madExcept умеет ловить утечки памяти с указанием строк где они произошли.

    fastmm сам по себе умеет многое.
    Здесь подробнее по технике ловле утечек с помощью fastmm (сама статью по ссылке можно пропустить, основное в комментах)
    http://tech.turbu-rpg.com/486/wanted-live-leak-detection-for-fastmm
    -
    Игорь

    ОтветитьУдалить
  2. Насчёт подсчёта неосвобождённых объектов - интересная тема, пишите однозначно!

    ОтветитьУдалить
  3. Обязательно напишу тогда. Я сейчас немного ушёл в переход с Delphi 7 на Delphi XE3. Но край - уже виден. Всё больше и больше тестов проходит.

    ОтветитьУдалить
  4. Вот относительно недавняя статья http://www.altdevblogaday.com/2011/12/24/static-code-analysis/ про статические анализаторы кода. Понятно, не для Delphi, а C++. Хотя и для Delphi что-то есть http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
    Pascal Analyzer/Codehealer смотрели? Audits/Metrics в среде Delphi есть.

    ОтветитьУдалить
  5. Дело в том, что мне были бы интересны анализаторы родные. Встроенные в среду. А СВОИ проблемы - я уже лет 10-ть как - решил :-) Скоро опишу как. И поскольку у меня есть СВОИ инструменты. То ЧУЖИЕ "навесные" решения - интересны -только в плане идей. Но всё равно - ОГРОМНОЕ ЧЕЛОВЕЧЕСКОЕ СПАСИБО.

    ОтветитьУдалить
  6. Я сейчас пишу БОЛЬШУЮ статью про подсчёт ссылок, контейнерные классы и т.п. На примесях конечно же. Там и про "следилку за объектами" будет. Но опубликую я её - когда закочу портирование на Delphi XE3. Ибо оно у меня теперь занимает 12 часов в сутки. Хочется добить...

    ОтветитьУдалить
  7. Да... Pascal Analyzer - я видел.. Пользовался.. Но не вкурил до конца если честно.. Но вещь - ПОЛЕЗНАЯ...

    ОтветитьУдалить
  8. За примеры ошибок и способы их решения, конкретные тесты, помогающие их выловить заранее спасибо! Кстати, был совсем недавно вебинар об ошибках при переходе в Delphi/Builder на x64. Там классы ошибок с адресной арифметикой показали. На viva64.com есть запись. Я понял, в XCode лучше, чем в Delphi, а в Visual Studio /analyze еще лучше :)
    David I говорил, что улучшить инструменты статического анализа - одна из самых важных задач развития Delphi. Теперь об этом еще и Марко Кэнту можно спросить.

    ОтветитьУдалить
  9. ПОЖАЛУЙСТА! Буду рад помочь! Кидайте интересующие темы кстати если что. Опыт у меня - обширный. Но я пока не понял - что интересно людям, а что неинтересно. Я вот пытаюсь про примеси писать - но похоже - неинтересно. Давайте напишу про что-нибудь ещё... Если интересно... Я кроме БД и SQL - многое попробовал.. И рад бы поделиться...

    А примеры КОНКРЕТНЫХ тестов - ещё БУДУТ! Просто во-первых они должны КОМПИЛИРОВАТЬСЯ, а во-вторых - не нарушать права работодателя.

    xCode - не лучше. Он просто - ДРУГОЙ.. А анализатор - ДА - очень полезный.. я им ОЧЕНЬ впечатлился... Мне даже сначала это показалось "магией"..

    VS - не видел...

    И ещё... Если вы в Москве, ну или недалеко (скажем в Твери или Питере или около того), то предлагаю - "попить пива"... Ну пообщаться лично.. ВСЕМ интересующимся кстати... Просто у меня с вербальным общением - вроде бы неплохо, а вот с письменным - БЕДА... Не всё я могу "на бумаге донести".. А на "пальцах" - может быть.. Ну и у вас я бы чего полезного почерпнул бы... Мне - было бы интересно...

    У меня - ОЧЕНЬ умные и интересные коллеги, но я с ними уже ОЧЕНЬ давно работаю. А "снаружи" - лет 10-ть точно ни с кем не общался...

    ОтветитьУдалить
  10. eurekalog тоже умеет ловить утечки

    ОтветитьУдалить
  11. Слышал о таком :-) СПАСИБО!
    Просто я то уже сижу на своих инструментах.. Но за информацию - СПАСИБО! Пишите ещё...

    ОтветитьУдалить
  12. Про тесты кстати - http://18delphi.blogspot.com/2013/04/delphi-xe.html

    Этот тест проходит конечно же. Но он - ПОЛЕЗНЫЙ.

    ОтветитьУдалить
  13. madExcept - не слышал. Посмотрю обязательно. СПАСИБО!

    ОтветитьУдалить
  14. Идея на моих объектах - банальна. Я перекрываю NewInstance и FreeInstance через примеси и складываю все объекты в глобальную мапу. И на выходе вижу статистику неосвобождённых объектов. И если вчера статистики не было, а сегодня я что-то поправил - то я гоняю тесты и вижу статистику неосвобождённых объектов. Значит я - ЗНАЮ - где их искать. Ну и плюс информация из JEDI.

    ОтветитьУдалить
  15. Повторю то, что уже писали выше.
    Для поиска утечек памяти - бесплатный FastMM (полная версия - с fastmm.sf.net) отлично с этим справляется, показывая как число неосвобождённых объектов, так и название файла и номер строки в которой этот объект создавался. Помимо этого он также может показывать места где используются уже освобождённые объекты, интерфейсы (этим грешат некоторые разработчики компонентов), и проверять кучу на повреждения.
    О борьбе с утечками памяти и использовании Eurekalog, Fastmm и MadExcept очень хорошо написал Gunsmoker. Вообще, очень рекомендую почитать (лучше даже прочитать) его блог - там очень много очень хорошо структурированного материала по отладке и поиску ошибок в коде.

    О статическом анализе кода:
    * В Delphi есть встроенные QA Audits. Их имеет смысл использовать если установлена Delphi в редакции Enterprise, Architect или Ultimate. В Professional редакции все самые интересные проверки отключены.
    * Есть сторонние инструменты: Peganza Pascal Analyzer, Code Healer.
    Но конечно, такого богатого выбора функционала как в лучших анализаторов для C/C++, в Delphi я не встречал.

    ОтветитьУдалить
  16. Ещё раз :-) Когда я писал свой подсчёт объектов и памяти - никакой этой красоты не было :-) Да FastMM не было :-)
    А что до Enterprise - дорого. А в xCode - "из коробки". Чем и поразился. Собственно что и было написано.

    А так - спасибо конечно :-) Буду читать. А блог gunsmoker'а - конечно читал/читаю. Проникся уж давно :-)

    ОтветитьУдалить
  17. > Когда я писал свой подсчёт объектов и памяти - никакой этой красоты не было :-) Да FastMM не было :-)
    Но теперь они есть и про них известно. Чем своё лучше?

    ОтветитьУдалить
  18. Да ничем :-) Кроме того, что своё - решение проверенное. А чужое - ещё смотреть надо. А вы просто так интересуетесь? :-)

    ОтветитьУдалить
  19. Просто, потому что интересно, есть ли ещё что-то в этой области, что ещё нереализовано в FastMM.

    ОтветитьУдалить
  20. Не могу сходу сказать. У меня у самого "реализовано" гораздо меньше, но "мне хватало". В FastMM реализовано - гораздо больше. И более общо. Наверное "мне" - хватит. Но не факт, что я сразу сменю "самокат" на "феррари".

    К чему я вообще про контроль за ресурсами? Да к тому, что по моим скромным наблюдениям - далеко не все о нём вообще когда-нибудь задумывались. Судя по тому открытому коду, который я видел. А видел я его - много.

    Собственно - неплохо, что тема нашла хоть какой-то отклик. Я так понимаю, что у корифеев.

    ОтветитьУдалить
  21. > К чему я вообще про контроль за ресурсами? Да к тому, что по моим скромным наблюдениям - далеко не все о нём вообще когда-нибудь задумывались. Судя по тому открытому коду, который я видел.

    Я тут совсем недавно нашёл штуки 3 ошибки в сторонних библиотеках (платных, кстати).
    А началось всё с того, что через некоторое время после очередного обновления 2х сторонних библиотек, программа начала плеваться Access Violation-ами. Причём плеваться только при открытии одной определённой формы. И каждый раз вылет происходил на разной строке в разных методах. Ну в общем, понятно что что-то портит память, но как же узнать кто именно? И тут на помощь пришёл FastMM. Повключал я у него все отладочные флаги, какие только нашёл, включая проверку целостности Heap-а при каждом выделении памяти, обнаружение использования освобождённых указателей (а контроль за утечками памяти и так всегда включен).
    И тут началось. Вместо AV при открытии той формы, стал получать AV при старте программы, при выходе и ещё в паре мест. Как оказалось, одна из TMS-ных библиотек, спокойно обращается к указателям освобождённых объектов, как будто так и надо. И всё это даже каким-то чудом работает (т.е. конечно понятно каким), пока не включишь в проект FastMM с отладочными флагами. В общем, пока я искал того, кто у меня в программе память поганит, я исправил в TMS-ной библиотеке 2 или 3 таких ошибки. Причём, как оказалось, ни одна из них не была виновата в моём AV.
    И только после, наконец, добрался до своей ошибки. И-таки даже нашёл и отписал автору, и автор поблагодарил и ответил, что он уже в курсе и прислал исправление, но это уже совсем другая история.

    Я это всё к тому клоню, что Ferrari - оно такое Ferrari. ;)

    ОтветитьУдалить
  22. Поучительно :-)

    Я уж написал, что и у нас нашёл :-) Место, где ездят :-)

    Более менее закончу с портированием, займусь теорией :-)

    ОтветитьУдалить
  23. Я уж написал, что и у нас нашёл - http://18delphi.blogspot.com/2013/04/blog-post_4535.html

    ОтветитьУдалить