Есть ли будущее у DELPHI?

Цитата D_KEY @ 19.11.12, 15:27

Кстати, он занимается объектами, а не только памятью.

Разве он вызывает какие-то деструкторы? Ну в некоторых странных языках да, есть так называемые «финализаторы». Но на то они и странные языки. =)

Или может GC вызывает инициализатор, который задает начальное состояние объекта?

Цитата korvin @ 19.11.12, 14:39

Какая ж это потеря, если ты их явно сохранил в g_List? =) Речь не о потере в каком-то конкретном месте, а потере во всей программе, так что ты программно сам не можешь до них достучаться.

Слушай Корвин, я твой код модифицировал? Нет! Я сделал что ты просил? Да! Читаем про то какие были условия:

Цитата korvin @ 19.11.12, 13:35

Цитата

Это уже заплатка плять, как и в твоем случае с сылками. Я могу перегрузить оператор new/delete, и запоминать в отдельной переменной то что выделил, и возьму удалю там вот память, но код этот написанный тобой я трогать не буду. Это докажет тебе что это не утечка? А?

Конечно, ты же удалил память и не потерял ссылки. =)

Какие у тебя притензии к моему коду? Я так захотел сделать, как ты говоришь этот код я написал не просто так, а вдруг я вот так захотел сделать. Кто мне помешает? Так выходит случай выделения памяти в цикле(в примере выше) там нетутечки памяти, верно ведь? Или ты сам себе начнешь противоречить?

Цитата --Ins-- @ 19.11.12, 15:28

И то и другое решение - это не решение, это заплатка для устранения мемлика

Естественно бажный код надо править, чтобы он больше не создавал проблем, но мы же немного не об этом.

Цитата korvin @ 19.11.12, 14:39

так что ты программно сам не можешь до них достучаться.

Я же тебе показал на простейшем примере, что нет такого "программно сам не можешь до них достучаться", всегда можно до них достучаться особенно из под С++. Вот в java или C# может быть там ты и не достучишься, а в С++ достучишься, в этом ведь весь и прикол.

Цитата D_KEY @ 19.11.12, 15:29

А вот поиск "потерянных" ссылок - достаточно легкая задача, потому ты легко найдешь тулзы по вкусу.

Так, еще раз: как мне освободить этот участок памяти?

Добавлено 19.11.12, 15:38

Цитата KILLER @ 19.11.12, 15:37

Я же тебе показал на простейшем примере, что нет такого "программно сам не можешь до них достучаться", всегда можно до них достучаться особенно из под С++. Вот в java или C# может быть там ты и не достучишься, а в С++ достучишься, в этом ведь весь и прикол.

Как это сделать стандартным менеджером памяти?

Цитата korvin @ 19.11.12, 15:38

Как это сделать стандартным менеджером памяти?

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

Цитата korvin @ 19.11.12, 15:38

Как это сделать стандартным менеджером памяти?

Как ты сделаешь это стандартным менеджером памяти для C#, Java ? Можно перезаргузить программу и вуаля, стандартным менеджер памяти очистит данные, своего рода GC. Закончилась память, рестартанули прогу и делов, работаем дальше...

Добавлено 19.11.12, 15:55
А еще есть всякие функции для работы с хипом, это еще до них не дошли, просто на банальном примере перегрузке операторов я тебе показал, что ситуация когда "ссылка недоступна" обходится даже без изменения кода. А явовский GC писали паходу на Java с GC ? Или там черная магия какая то? Или как он там очищает память от объектов?

Сообщение отредактировано: KILLER - 19.11.12, 15:57

Цитата KILLER @ 19.11.12, 15:45

А явовский GC писали паходу на Java с GC ?

Ну всякие Jikes VM на Java написаны вроде как.

Цитата D_KEY @ 19.11.12, 15:44

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

Я бы сказал рефлексией, но допустим, что ее нет.

Можно переподписать всех «активных» подписчиков (мы можем это сделать, т.к. имеем на них другие ссылки), предварительно отписав всех.

Или мы и это не можем (какие-то из подписчиков сильно чужие и операция их подписки нам недоступна, а часть из них забывают отписываться)?

Добавлено 19.11.12, 16:03

Цитата KILLER @ 19.11.12, 15:45

Можно перезаргузить программу и вуаля, стандартным менеджер памяти очистит данные, своего рода GC. Закончилась память, рестартанули прогу и делов, работаем дальше...

Это каждый может, но мы же вроде говорили про 24/7 и исправление в рантайме, не?

Добавлено 19.11.12, 16:04

Цитата KILLER @ 19.11.12, 15:45

А еще есть всякие функции для работы с хипом, это еще до них не дошли, просто на банальном примере перегрузке операторов я тебе показал, что ситуация когда "ссылка недоступна" обходится даже без изменения кода.

Ты показал лишь как сделать ссылку доступной. Я могу таким же образом сохранять подписки и отписываться от них.

Сообщение отредактировано: korvin - 19.11.12, 16:04

Цитата korvin @ 19.11.12, 16:02

Это каждый может, но мы же вроде говорили про 24/7 и исправление в рантайме, не?

И как ты собрался список дропать в рантайме или юзать память которая за этой ссылкой ? Ты ведь именно такие способы разруливания ситуации ЕМНИП предлогал. А так банально рестартануть прогу, одно из способов очистки памяти и всяких заблудших ссылок...

Цитата korvin @ 19.11.12, 16:02

Ты показал лишь как сделать ссылку доступной. Я могу таким же образом сохранять подписки и отписываться от них.

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

Добавлено 19.11.12, 16:42
А вот тут есть описание всяких там функций, с помощью которых на том же С++ можно свой GC заколбасить... Ну или подобие...

Прикреплённая картинка

Цитата _lcf_ @ 19.11.12, 16:50

Прикреплённая картинка

Аналогия некорректна, да и фраза не соответствует картинке. Мусорные контейнеры кто вывозить будет? А перерабатывать мусор? Или куда ты предлагаешь девать все то искусственное, что производит человек?

Добавлено 19.11.12, 17:59

Цитата KILLER @ 19.11.12, 16:22

И как ты собрался список дропать в рантайме или юзать память которая за этой ссылкой ? Ты ведь именно такие способы разруливания ситуации ЕМНИП предлогал. А так банально рестартануть прогу, одно из способов очистки памяти и всяких заблудших ссылок...

Ну допустим у нас есть способ изменять программу в рантайме, как в CL или в ST. Но есть и другая постановка задачи: исходник бажного модуля/библиотеки/или-че-там-у-нас-течет нам недоступен, переписывать — долго, пока не переписали необходимо сделать костыль-обертку (workaround или как это там называется по-импортному), чтоб не текло, временную заплатку. Что будем делать?

Цитата KILLER @ 19.11.12, 16:22

Но ведь это не решение проблемы... Память ведь всеравно в пустую расходуется.

Нет, понятно, что бажный код в итоге надо приводить в порядок, но мы же не это обсуждаем.

Цитата korvin @ 19.11.12, 17:53

Ну допустим у нас есть способ изменять программу в рантайме, как в CL или в ST. Но есть и другая постановка задачи: исходник бажного модуля/библиотеки/или-че-там-у-нас-течет нам недоступен, переписывать — долго, пока не переписали необходимо сделать костыль-обертку (workaround или как это там называется по-импортному), чтоб не текло, временную заплатку. Что будем делать?

При желании можно сделать все что захочешь, хоть свою ось написать которая сама будет сканировать процессы на наличие невалидных ссылок и т.д. Все зависит от того что ты в итоге хочешь получить. Но, обсуждать тут костыли мне кажется лишнее. Можно написать обертку которая будет сама запускать процесс и рестартовать его, можно почитать рихтера того же, внедрица в адресное пространство процесса и попробовать что то сделать там, но есть очень большая вероятность завершиться аварийно, возможно есть какие то тулзовины которые уже этим занимаются, я незнаю, я такой херней на практике не страдал, если либа течет и очень сильно, то выбросить такую либу и взять аналог, если уже сроки поджимают, а ты юзаешь либу которая течет - то ты ССЗБ, что посеешь то и пожнешь как говорится...

Цитата korvin @ 19.11.12, 17:53

Нет, понятно, что бажный код в итоге надо приводить в порядок, но мы же не это обсуждаем.

А что? В каком языке будут костыли длинее и красивее ? Или что мы обсуждаем то?

Цитата _lcf_ @ 19.11.12, 16:50

а вот некоторые языки таки убирают

Цитата korvin @ 19.11.12, 15:33

Разве он вызывает какие-то деструкторы?

Он уничтожает объекты(именно объекты, поскольку отслеживает мусор он по недоступности объекта. Вызывает он при этом финализатор или нет - разговор отдельный.
Но, заметь финализаторы используются в императивных языках. Там они иногда будут нужны. И это возвращает нас к разговору об опциональности GC.

Цитата

Или может GC вызывает инициализатор, который задает начальное состояние объекта?

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

Добавлено 19.11.12, 20:36

Цитата korvin @ 19.11.12, 16:02

Цитата D_KEY @ 19.11.12, 15:44

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

Я бы сказал рефлексией, но допустим, что ее нет.

Можно переподписать всех «активных» подписчиков (мы можем это сделать, т.к. имеем на них другие ссылки), предварительно отписав всех.

Распиши, как ты будешь искать "активных" подписчиков.

Добавлено 19.11.12, 20:41

Цитата korvin @ 19.11.12, 15:06

Цитата D_KEY @ 19.11.12, 15:03

Я почему-то даже говорить об этом "языке" не хочу

А о каком хочешь кроме C++? Oberon подойдет?

Ладно, фиг с ним, давай о Go. Расскажи, почему там нельзя было сделать сборщик опциональным средством?

Добавлено 19.11.12, 20:43

Цитата Besha @ 19.11.12, 19:53

Цитата _lcf_ @ 19.11.12, 16:50

а вот некоторые языки таки убирают

Их и обсуждаем.

Добавлено 19.11.12, 20:45
Да, на всякий случай поясню. Я ничего не имею против сборки мусора, но она должна быть(в случае императивных языков) дополнительной фичей, а не фундаментом построения языка. ИМХО.