Это реализуется при помощи _CrtMemCheckpoint, _CrtMemDumpAllObjectsSince (про это было) и _CrtMemDifference, про которую не упомянул, наверное зря.
А вообще идеология простая, перед открытием проекта/сцены/модели делаем _CrtMemCheckpoint, после закрытия — _CrtMemDumpAllObjectsSince. Все новосозданные и не удаленные объекты являются подозрительными на утечку (но не обязаны ей быть).
Субъективно очень даже снижает. Вообще надо бы взяться и оттестить, а то тезис
>Он, оказывается, работает быстрее, чем ручные delete. Раза в полтора.
немного удивляет и, быть может, подвох в чем-то другом.
_CrtDumpMemoryLeaks может врать только в одном ключе — он пропускает объекты выделенные вручную через HeapAlloc, GlobalAlloc. Как отсечь глобальные и статические объекты я написал, и да, их использованием MFC, увы, славится. Строку и имя файла определяет, если переопределить new, но «прыгать» по ней не будет. Но и время анализа и исправления утечки обычно больше, чем навигации по коду, всё-таки.
В данном случае необходимость переопределения new имеет исторические корни, не в этом смысл. А Debug CRT тоже имеет средства обнаружения неициализированных данных (и обращений к уже освобожденным), выходов за границы массива. В сочетании с AppVerifier можно обрабатывать и попытки чтения/записи по неверным адресам. А вообще, Windows-программисты тоже должны как-то жить :)
Google heap checker насколько я понял только под Linux. А вообще, насколько бы ни были хороши внешние инструменты, тут рассматривается несколько другая задача — можно назвать это самодиагностикой. Отдав программу на предрелизное тестирование, например, мы убедимся, что у программы нет серьезных утечек. А если вдруг есть, то и поймем — где они. Главное, тестеров не придется учить новым штукам. Для маленьких проектов это актуально.
Да, в VC6 утечки выводились автоматически, поскольку по умолчанию был установлен флаг _CRTDBG_LEAK_CHECK_DF. С семерки — нет, но его можно включить через _CrtSetDbgFlag(). Ну или явно использовать _CrtDumpMemoryLeaks() (в действительности, оно и звалось перед выходом из main() ).
Спасибо за замечание; при тестировании использовалось MSVC9 на Vista SP2. Тот же порядок (но немного бОльшие цифры) выходят для тестового приложения запущенного на XP SP3. «Час расплаты» целиком относится только к Win32.
Да, для больших (хотя это понятие для каждого своё) проектов этот метод не пригоден, согласен. А «умные указатели» тоже не стоит воспринимать как панацею, от «лишнего» add reference они не застрахованы (человеческий фактор), а найти его иногда крайне сложно (а, интересно, Valgrind справится? особенно меня интересует эта проблема для CComPtr).
В этом есть толика здравого смысла — еще бы сопоставить ошибкам уникальные идентификаторы и можно создать базу знаний по ошибкам (народными средствами или же силами производителя).
На клиенте. Ему же надо что-то отправить на сервер, так вот перед этой отправкой происходит то, что можно назвать «процессом получения».
Хотя в более глобальном смысле мне не ясно, зачем гнать кучу данных на сервер (и «присылать громадный файл»), чтобы обратно получить часть этой же информации + карты (для получения которых достаточно было бы мизерного количества точек).
Я не думаю, что это требование вызванное реальными проблеамами ПО, скорее маркетинговый ход, чтобы продать новое железо. Ну и какие-то гарантии комфортной работы юзерсофта.
Можно удалить все точки, которые лежат «почти» на прямой относительно двух соседей — время такой проверки O(1) для каждой точки (делаем в процессе получения данных). Для «путешествий» по городу — самое оно.
> Открытая передача логина/пароля по FTP.
Не стоит забывать и про открытое хранение пары логин-пароль в ftp_param.txt, а ведь можно было просто дать write-only доступ записи анонима.
> rem зальем полученный архив на FTP
А если архив не будет создан из-за какой-либо ошибки? Надо бы проверять errorlevel.
А вообще идеология простая, перед открытием проекта/сцены/модели делаем _CrtMemCheckpoint, после закрытия — _CrtMemDumpAllObjectsSince. Все новосозданные и не удаленные объекты являются подозрительными на утечку (но не обязаны ей быть).
>Он, оказывается, работает быстрее, чем ручные delete. Раза в полтора.
немного удивляет и, быть может, подвох в чем-то другом.
В качестве оптимизации можно тащить с собой base64 от gif (ну или lzw от bmp) а рендерить в div'ы джаваскриптом через DOM, да и много как ещё можно.
А вообще, забавно.
А остается только использование MD4 и коммуникации.
Да, для больших (хотя это понятие для каждого своё) проектов этот метод не пригоден, согласен. А «умные указатели» тоже не стоит воспринимать как панацею, от «лишнего» add reference они не застрахованы (человеческий фактор), а найти его иногда крайне сложно (а, интересно, Valgrind справится? особенно меня интересует эта проблема для CComPtr).
Или как обычно, «подумаешь лишние детали остались, и так всё работает».
Хотя в более глобальном смысле мне не ясно, зачем гнать кучу данных на сервер (и «присылать громадный файл»), чтобы обратно получить часть этой же информации + карты (для получения которых достаточно было бы мизерного количества точек).
А вообще, выглядит крайне недостоверно.
Не стоит забывать и про открытое хранение пары логин-пароль в
ftp_param.txt, а ведь можно было просто дать write-only доступ записи анонима.> rem зальем полученный архив на FTP
А если архив не будет создан из-за какой-либо ошибки? Надо бы проверять errorlevel.