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

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

MTD>>>Нет. shared_ptr реально нужен в 1 случае из 200.

F>>как тогда предлагаешь управлять памятью?
Ops>Открой для себя контейнеры.

А что контейнеры ? Если нужна полноценная инверсия управления, то нужны замыкания, а следовательно и GC. Все, приехали.

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Кстати, вопрос: Dispose — это костыль (пардон, "паттерн") или нет?

Вот это http://msdn.microsoft.com/en-us/library/system.idisposable.dispose.aspx ?

Сам по себе метод не костыль — внешние ресурсы действительно нужно освобождать и (в отличие от случая с памятью) только программист знает как и когда. C# я не знаю, но, кажется, там этот интерфейс дополнительно поддерживается языком. Сейчас прочитал там про какие-то пляски с finalizer — вот это уже похоже на непроработанность. Больше с моими знаниями сказать сложно.

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

MTD>>Это не пример, а демагогия.

N>Не понял, где здесь демагогия.

Без конкретной постановки задачи — демагогия в чистом виде.

N>Сохранение callback (он же listener, он же delegate) — задача тривиальная и часто встречающаяся в прикладных программах.

Конечно. А вот вопросы владения вопросы вызывают.

N>Причем здесь C++? Ветка про подсчет ссылок.

Ты видимо что-то перепутал. Подсчет ссылок не единственная альтернатива GC.

MTD>>Я говорил о том, что проблема циклических сылок — проблема дизайна.

N>Нет, это проблема подсчета ссылок — простейшие вещи ведут к утечке памяти.

Не ведут.

N>Почему я должен уродовать архитектуру только для того, чтобы натянуть ее на технологию с неподходящей семантикой?

Наоборот, я призываю к простой и понятной архитектуре, тогда и не будет всяких последствий типа циклических ссылок.

N>Почему просто не взять язык с GC?

Потому, что это не серебрянная пуля.

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

N>Нет, давай вначале разберёмся с общим подходом. Ты настаиваешь на написании кода без циклических ссылок вообще? Или "без проблемы циклических ссылок"?

Без циклических владеющих ссылок.

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

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

MTD>Без конкретной постановки задачи — демагогия в чистом виде.

MTD>Конечно. А вот вопросы владения вопросы вызывают.

Не понимаю, что здесь так тяжело постигнуть.

Some s;
Publisher p;

s.publisher = p; // эту строчку ты не видишь, она - в недрах библиотеки/соседнем методе

p.subscriber = lambda (Event event) { s.doSomething(event.data) }

Если у нас подсчет ссылок, то мы уже приехали. Это простейший пример. На практике есть случаи повеселей, но их в двух словах не опишешь.

N>>Причем здесь C++? Ветка про подсчет ссылок.

MTD>Ты видимо что-то перепутал. Подсчет ссылок не единственная альтернатива GC.

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

N>>Нет, это проблема подсчета ссылок — простейшие вещи ведут к утечке памяти.

MTD>Не ведут.

См. пример.

N>>Почему я должен уродовать архитектуру только для того, чтобы натянуть ее на технологию с неподходящей семантикой?

MTD>Наоборот, я призываю к простой и понятной архитектуре, тогда и не будет всяких последствий типа циклических ссылок.

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

N>>Почему просто не взять язык с GC?

MTD>Потому, что это не серебрянная пуля.

Где утверждалось что-то про пулю?

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

КД>>Кстати, вопрос: Dispose — это костыль (пардон, "паттерн") или нет?

N>Вот это http://msdn.microsoft.com/en-us/library/system.idisposable.dispose.aspx ?
Да, я про него.

Попробуй соорудить реализацию объекта с Dispose в которой бы:
— было запрещено использовать объект после вызова Dispose.
— Dispose не "разрушал" объект, пока работают другие его методы.

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

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

N>>Нет, давай вначале разберёмся с общим подходом. Ты настаиваешь на написании кода без циклических ссылок вообще? Или "без проблемы циклических ссылок"?

R>Без циклических владеющих ссылок.

С владеющими ссылками нужно постоянно мысленно инспектировать граф объектов (что в нетривиальной программе быстро превращается в безумие) и профилировать, чтобы не вляпаться в утечку. С невладеющими — в висячий указатель. Чем шило лучше мыла? Еще, конечно, можно натянуть сову на глобус: подогнать программу под ограничения ручного управления. Как сказал бы Xbox 360 Kid: "The great thing about the reference counting isn’t delivering of functionality, it’s showing everyone online that I did".

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


MTD> но замечу, что циклические ссылки — проблема кривого дизайна

Это когда они стали плохим дизайном и почему

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

MTD>>>Нет. shared_ptr реально нужен в 1 случае из 200.
F>>как тогда предлагаешь управлять памятью?
Ops>Открой для себя контейнеры.

при чём тут контейнеры? мне их на каждый чих создавать?

MTD>>>Меня интересует твоя реализация.
F>>моя вполне классическая.
Ops>Ну так приведи, а не отмазывайся.

в гугле забанили?

Здравствуйте, Евгений Акиньшин, Вы писали:

MTD>> но замечу, что циклические ссылки — проблема кривого дизайна

ЕА>Это когда они стали плохим дизайном и почему

Уточнение — владеющие. Это из контекста понятно.

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

Ops>>Открой для себя контейнеры.
F>при чём тут контейнеры? мне их на каждый чих создавать?
Вроде же ты про управление памятью начал?

F>в гугле забанили?
Ну ок, отмазывайся.

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

N>Не понимаю, что здесь так тяжело постигнуть.

N>

N>Some s;
N>Publisher p;

N>s.publisher = p; // эту строчку ты не видишь, она - в недрах библиотеки/соседнем методе

N>p.subscriber = lambda (Event event) { s.doSomething(event.data) }
 
N>

Ну бред же написан Что нибудь из реальной жизни есть?

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

Ops>>>Открой для себя контейнеры.
F>>при чём тут контейнеры? мне их на каждый чих создавать?
Ops>Вроде же ты про управление памятью начал?

так как они помогут?

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

Я думаю, задача яйца выеденного не стоит.

"Ноды" и связи — это отдельный вещи (со своими счетчиками ссылок). И хранятся они отдельно. Связи ссылаются на "ноды". Кстати, связи могут выступать нодами для следующего уровня связей и так далее.

Вообще говоря, одним счетчиком тут не обойтись. Делается два счетчика — первый низкоуровневый (который убивает объект при обнулении), а второй отвечает за подсчет ссылок на объект внутри графа (когда обнуляется может уведомить "глобальный контейнер" о "ненужности" объекта).

Поверх этих "низкоуровневых" объектов, можно соорудить другой набор объектов (создаваемых динамически, то есть по-требованию) который бы упрощал получение входящих и исходящих связей для "нодов".

На первый взгляд — выглядит муторно. Но если есть шаблоны для конструирования подобных вещей, то такие конструкции создаются тоннами в рамках рабочего дня

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

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

MTD>>Давай на конкретном примере, я тебе напишу код без проблемы цикличных ссылок или признаю, что ошибался?

N>Конкретный пример: в метод объекта передается функция, которая сохраняется для последующего использования. Как узнать, что эта примитивная операция не создает цикла?

Это не конкретный пример, а конкретный способ решения.

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Попробуй соорудить реализацию объекта с Dispose в которой бы:
КД>- было запрещено использовать объект после вызова Dispose.
КД>- Dispose не "разрушал" объект, пока работают другие его методы.

Дотнетовский Dispose заточен под самый популярный сценарий — один владелец, объект гарантированно не будет использоваться в дальнейшем. Если явного владельца нет, но ресурс по-прежнему требуется освобождать, то надо считать ссылки или использовать API с continuation-passing. Я бы смотрел в сторону RX/тасков.

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

MTD>>>>Меня интересует твоя реализация.
F>>>моя вполне классическая.
Ops>>Ну так приведи, а не отмазывайся.

F>в гугле забанили?

Засчитано.

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

КД>>Попробуй соорудить реализацию объекта с Dispose в которой бы:
КД>>- было запрещено использовать объект после вызова Dispose.
КД>>- Dispose не "разрушал" объект, пока работают другие его методы.

S>Дотнетовский Dispose заточен под самый популярный сценарий — один владелец, объект гарантированно не будет использоваться в дальнейшем.

Кем гарантируется? Программистом?!

Упаси меня Господь закладываться на такие гарантии

> Я бы смотрел в сторону RX/тасков.

Не, спасибо (хоть бы ссылку дали, что-ли, для темных).

Я как-то по-старинке — прикрутил "неявный" счетчик ссылок к подобным объектам и закрыл эту тему для себя

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

MTD>Засчитано.

молодец, ни слова не сказал по теме.

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

MTD>Ну бред же написан Что нибудь из реальной жизни есть?

Этот бред имеет отдельную поддержку от языка в C# — http://msdn.microsoft.com/en-us/library/ms173171(v=vs.80).aspx . Наверное, от скуки они его туда 10 лет назад приделали, тебя потроллить. Это в качестве примера, в других языках это делают без дополнительного сахара. Охотно верю, что С++ — единственная среда, до которой новинки пятидесятилетней давности не дошли.