Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, remark, Вы писали:

VD>>>ОК. Тогда зачем вся эта тема? Ну, какова ее цель? Ведь конкретные люди сталкивались с конкретными проблемами и при работе с кучей С/С++. Почему ты не посвятил свою тему этому?

R>>А почему я не посвятил свою тему арбузам? Многим бы было интересно.
R>>А почему ты не посвящаешь свои темы организации кэшей современных процессоров? Мне было бы интересно!
R>>Или тут можно постить только по квотам от тебя?


VD>Так ответ на мой вопрос будет? Или дальше продолжишь заниматься демагогией?

Я не посвятил свой пост проблемам с кучей С/С++, просто потому что я посвятил свой пост другой теме. А посвящать посты всему я просто не могу.

Здравствуйте, VladD2, Вы писали:

[]

VD>ОК. Тогда зачем вся эта тема? Ну, какова ее цель? Ведь конкретные люди сталкивались с конкретными проблемами и при работе с кучей С/С++. Почему ты не посвятил свою тему этому?

Про проблемы с кучей с++ написано уже достаточно. А вот про проблемы с гц видимо не очень. Про гц принято писать, в основном, только в радужных тонах (только не тыкай меня в свою статью, где об этих неприятных эффектах упоминается).

Здравствуйте, remark

Вот еще тебе в копилку свеженький пример: An interesting memory leak in JRuby

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, remark

E>Вот еще тебе в копилку свеженький пример: An interesting memory leak in JRuby

Спасибо.
Вывод как я понял следующий. Там были [не очень] неявные ссылки между объектами, которые заставляли зависать в памяти очень большое дерево объектов.

А там ещё в коментах ссылка на ещё одну проблему:
http://tomcopeland.blogs.com/juniordeveloper/2007/09/tracking-down-a.html

Здравствуйте, remark, Вы писали:
R>Спасибо.
R>Вывод как я понял следующий. Там были [не очень] неявные ссылки между объектами, которые заставляли зависать в памяти очень большое дерево объектов.
Я так понял, что проблема близка к знаменитой беде с делегатами в .Net. Позволю себе напомнить, что неаккуратная подписка объекта на событие завешивает его в памяти навсегда.
Прелесть в том, что раз ссылок, кроме делегата, на объект нету, то шансов на отписку ~0.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, remark, Вы писали:
R>>Спасибо.
R>>Вывод как я понял следующий. Там были [не очень] неявные ссылки между объектами, которые заставляли зависать в памяти очень большое дерево объектов.
S>Я так понял, что проблема близка к знаменитой беде с делегатами в .Net. Позволю себе напомнить, что неаккуратная подписка объекта на событие завешивает его в памяти навсегда.
S>Прелесть в том, что раз ссылок, кроме делегата, на объект нету, то шансов на отписку ~0.

А можешь пример привести, как можно неаккуратно подписаться на событие.

Здравствуйте, remark, Вы писали:

R>А можешь пример привести, как можно неаккуратно подписаться на событие.
Пример можно найти в SVN RSDN@Home двух-трех-летней давности
Обычная штука, к примеру: форма подписывается на уведомления об изменении модели, и при закрытии забывает отписаться. Всё, копец. Закрытые формы копятся и копятся.
R>

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, remark, Вы писали:

R>>А можешь пример привести, как можно неаккуратно подписаться на событие.
S>Пример можно найти в SVN RSDN@Home двух-трех-летней давности
S>Обычная штука, к примеру: форма подписывается на уведомления об изменении модели, и при закрытии забывает отписаться. Всё, копец. Закрытые формы копятся и копятся.

На слабых ссылках нужно было это делать. Было бы помедленнее, но зато не нужно заботиться от отписывании.

Здравствуйте, Sinclair, Вы писали:

R>>Вывод как я понял следующий. Там были [не очень] неявные ссылки между объектами, которые заставляли зависать в памяти очень большое дерево объектов.
S>Я так понял, что проблема близка к знаменитой беде с делегатами в .Net.

Не, тут просто баг. Вместо очищения ссылки она запоминается. Даже если бы не было замыкания со ссылками на окружение, то это была бы утечка всё равно. Просто она была бы мизерная и её никто бы не стал искать.

Здравствуйте, alexeiz, Вы писали:
A>На слабых ссылках нужно было это делать. Было бы помедленнее, но зато не нужно заботиться от отписывании.
Есть реализации делегатов на слабых ссылках; но встраивать слабость делегатов в платформу, имхо, спорный вариант.

Sinclair wrote:
> A>На слабых ссылках нужно было это делать. Было бы помедленнее, но зато
> не нужно заботиться от отписывании.
> Есть реализации делегатов на слабых ссылках; но встраивать слабость
> делегатов в платформу, имхо, спорный вариант.
Более сильный вариант: встраивать делегаты в платформу — спорный вариант
(ИМХО).

Здравствуйте, Cyberax, Вы писали:
C>Более сильный вариант: встраивать делегаты в платформу — спорный вариант
C>(ИМХО).
Я так не думаю. Без поддержки платформы состряпать свои делегаты, мягко говоря, трудно. Вряд ли удастся обеспечить ковариантность, и будут проблемы с быстродействием.

Sinclair wrote:
> C>Более сильный вариант: встраивать делегаты в платформу — спорный вариант
> C>(ИМХО).
> Я так не думаю. Без поддержки платформы состряпать свои делегаты, мягко
> говоря, трудно. Вряд ли удастся обеспечить ковариантность, и будут
> проблемы с быстродействием.
Вполне можно — достаточно иметь ковариантность для интерфейсов. От языка
разве что синтаксический сахар можно было бы добавить.

Здравствуйте, Sinclair, Вы писали:

S>Пример можно найти в SVN RSDN@Home двух-трех-летней давности
S>Обычная штука, к примеру: форма подписывается на уведомления об изменении модели, и при закрытии забывает отписаться. Всё, копец. Закрытые формы копятся и копятся.

Там все было сложнее. Там был синглтон к событиям которого подписывались. Иначе бы подписчики умерли бы вместе с формой.

Здравствуйте, Sinclair, Вы писали:

S>Есть реализации делегатов на слабых ссылках; но встраивать слабость делегатов в платформу, имхо, спорный вариант.

Я бы сделал более сильное утверждение: Встравивание делегатов в платформу — это ошибка.

Здравствуйте, Sinclair, Вы писали:

S>Я так не думаю. Без поддержки платформы состряпать свои делегаты, мягко говоря, трудно. Вряд ли удастся обеспечить ковариантность, и будут проблемы с быстродействием.

Разработчики Немерле и как я понимаю Скала + F# c этим справились.

Тут вопрос в другом даже. Делегаты сами по себе безграмотно спроектированы. В них:
1. Ошибочно заложена поддержка списка фунций, что перебор для большинства применений (кроме событий).
2. Они задают уникальный тип и получается, что два делегата с одной сигнатурой несовместимы между собой.

Вместо делегатов нужно было реализовать функциональный тип. Он должен описываться только сигнатурой и позволять ссылатьс ятолько на одну функцию. Если кому-то нужно создать список ссылок на фунции, то его можно поместить в массив или List<функциональный тип>.
А вот для создания уникальных типов в язык или платформу нужно было бы ввести "строгий" typedef. Типа:

type T1 = int;
T1 a = 1;
int b = a; // Ошибка времени компиляции!

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