С чего ты взял, что я вообще пытался это делать? Я как бы работаю не по аверству, мне чужие семплы анализировать не нужно. "Если тебя словили то будь честным признай, незачем пытаться извернуться как рыба на сковороде, бессмысленно." (с)
Ну в том же вб6 на уровне компилятора реализовано разрешение некоторых таких ситуаций, а именно при использовании событий (IConnectionPoint/IConnectionPointContainer), когда к примеру в классе есть поле объект на события которого подписывается класс. Т.е. сам класс держит ссылку на этот объект, а объект держит ссылку на класс используя логику Connection-Point'ов.
так при завершении работы процесса все равно ресурсы освободятся, это не ядро же. Хотя общую мысль понял, да. Не знаю, ООП мне не нужно, вот что действительно в Си доставляет много головной боли - память, конкретно heap corruption. Особенно чистый Си без црт , была ошибка на которую потратил месяц и так и не решил (только другой человек помог), а все из-за банальной опечатки.
Ну для начала можно попробовать прогнать статические анализаторы типа CppCheck и PVS-Studio, ты удивишься, сколько они могут находить типичных проколов цешников. Потом, если не помогло, можно поэкспериментировать с дебажной кучей или динамическими анализаторами типа: https://www.teamblue.unicomsi.com/products/purify/ и оными.
Microedition, Rel, pvs студию пробовал, хорошая вещь, но конкретно тот баг не нашла. Там была какая фишка - структура вида NODE { dword x; PNODE next; } или чето такое; это было частью еще одной огромной структуры и т.д. Суть ошибки в том, что память для нового элемента выделялась кaк HeapAlloc(sizeof(PNODE) , т.е. выделялся размер указателя. При этом - на 32 бит все работало супер , вообще никаких ошибок, а вот на 64 бит время от времени софт падал. И неясно было почему, т.к. перезаписывались какие-то другие участки памяти. Вручную нашел ошибку один специалист (с этого форума), потратил много времени и не знаю какие методы, но нашел.
При возникновении исключения можно будет корректно освободить ресурсы. Тот же самый подход как и с goto CleanUp только + еще поддерживаются исключения. Это при завершении процесса, а если продолжить работу тот тут уже может быть все печально. К примеру неразлоченная критическая секция повесит другие потоки запрашивающие доступ навсегда. Это только один пример. Вот как раз языки с безопасной концепцией исключают подобные ошибки. Прелесть плюсов в том что там можно писать в С стиле, а когда нужно можно использовать ООП/шаблоны и т.п. вещи. Как выгода например работа с COM на плюсах проще реализуется.
M0rg0t, > И неясно было почему, т.к. перезаписывались какие-то другие участки памяти. Наверно ты не знаком с отладкой, те не можешь ничего толком отладить. Если есть ошибка, то есть поток последовательность выборки, пересылки данных, которые элементарно находятся в отладчике. Известно место исключения - его причина источник данных и так назад по цепочке. Для решения таких ошибок даже автоматика не нужна(в данном случае было бы то самое deref under ref), тем более системная куча содержит множество механизмов диагностики, стектрейс логгеры в крайнем случае оптимизация может выключаться полностью(pageheap", когда под каждый блок выделяется физическая страница - сделано спецом для поиска таких ошибок с произвольной выборкой на запись, тк рандом запись испортит всю среду менеджера памяти его структуры). Что выше обсуждаете про исключения - это не верное понимание, исключение в сишке нельзя назвать хардверным, это механизм обмена данными. На какое то событие бросается нотифи, не эффективный конечно механизм. Причём обычно это делается через интернал компилера механизм, не затрагивая системный механизм ловушек. Тоесть никакое исключение не возникает, просто доставляется сообщение между частями апп.
Rel, УК не читал, за знание срок не дают. Лишь когда используешь что знаешь заберут. Кстате я на вашем форуме нашёл знакомые мне механизмы, что то по обратным вызовам гуя. https://xss.is/threads/49888/ что интересно сможет ли весь тот ресурс собрать рабочую сборку пусть хоть пригодную к отладке или же просто пройти отладчиком сам механизм без сборки. Судя по коментам там даже не понимают что такое компилер. Это жесть, просто слов нет. Не удивительно что ты выбрал соотв окружение такое же тупое. Но зато там можно барыжить примитив текстами, яшечка тоже это не потерял.
Ну ты довольно много слов сказал, хотя утверждаешь, что их нет. Это что-то из психологии, наверное. Инди, не нужно завидовать. Я понимаю, что ты своего места найти не можешь. Но обвинять людей в том, что какое-то комьюнити их ценит, это полный бред.
Microedition, > Ты хоть раз в жизни отслеживал многопоточное приложение? Отслеживал, все которые были на крэклабе, тоесть всё. Он так разработан(дий), что нужные операции атомарны; никогда небыло проблем с синхроном. > Отладчик укажет лишь на место проявления ошибки Нуби пришёл и тут говорить что я кнопки не знаю какие нажать. Чувак ты сошёл с ума, я архитектуру знаю вдоль и поперёк как всё устроено и отладчик для меня просто развлекуха, в отличие от тебя. Желательно конечно ядерный, в юзер нужно большое терпение. Опыт все дела.. Ты же застрянешь на самом примитиве, не смотря на твои понты.
Microedition, > Отлаживал то есть, описка у меня. Не опечатка просто потому что уже иные инструменты давно используются, там отслеживается, а не отлаживается. Юзер отладчик это игрушка, детский инструмент.
Ошибки перезаписи за пределы выделенной памяти хипа тяжело отыскиваются. Даже валидация хипа и т.п. отладочные штуки не всегда могут помочь, + еще если ошибка не всегда происходит. Да, используя визор (если я правильно употребил термин) можно построить карту выделенной памяти в хипе и уже по инструкциям выборки смотреть где идет перезапись. В самом простом случае можно просто вести лог выделений/освобождений памяти в хипе. При возникновении исключения смотреть уже что привело к этому и смотреть к какому блоку памяти относится. Потом уже анализировать место откуда произошла перезапись. В OllyDbg/x64dbg это легко делается Conditional Breakpoint'ами.
Rel, Вали на xss, твой акк тут давно следует забанить как человек не честный. --- Сообщение объединено, 27 мар 2021 --- Thetrik, > При возникновении исключения смотреть уже что привело Чем же ты это посмотришь, у тебя нет инструмента.
M0rg0t, > Сомневаюсь, что ты бы что-то там нашел. Были трудно решаемые ошибки, единственный семпл который я помню patric" - автоматика не могла пройти из за тайминга https://wasm.in/threads/aktivnost-prilozhenija.33360/page-2#post-410960, тк была не бинарная трансляция возникала недопустимая задержка, соотв возникала файловая ошибка с эксклюзивным(что за термин корявый) доступом. Рандом запись легко отслеживается перезапуском апп, так что не нужно усложнять.
Я изначально написал: Что подразумевает под собой возможность отладки и проявления бага на целевой машине.
