Здравствуйте, MxMsk, Вы писали:
MM>Погоди погоди. Я же просил нормальный, реальный пример. Понятно, что можно напридумывать кучу костылей. Я привел пример, когда отдаю контрол в несколько лямбд. На что был получен ответ, типа это не проблема для C++. Однако, внятного решения — автоматической заботы об объекте, вырванном из дерева, мне никто не приводит. Вон, как что не скажешь про C++, у FR на всё ответ "при желании можно", но что-то пример продакшн уровня реализации этих желаний никто не приводит, только самопальные костыли... или Python!
Реализации ссылок на любой вкус есть в TR1/boost, сигналы есть в boost/QT. Например, в QT есть QPointer<T> — надо "вырвать" объект из дерева — сказали ему delete obj и он автоматически будет из него "вырван" (все указатели на объект станут равны 0) А вот в .net удаление любого объекта из дерева, это хождение по граблям — все ссылки владеющие, а WeakReference без "внешней поддержки" использовать практически нельзя.
MM>Проблемы циклических ссылок в .Net нет. И потом, я не уверен, что разрыв связи — это правильный путь. Если кто-то подписался на event, значит это ему нужно. Да и weak event при желании реализовать можно. А лучше научится реализовывать GUI без этих заморочек.
"Если кто-то подписался на event, значит это ему нужно." — получается паттерн "буратино вырос". после этого, истинный владелец "буратин" будет ломать голову над тем, как их всех родить обратно. Weak Event в том-же WPF это как раз и следствие того, что "проблемы циклических ссылок в .Net нет".
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[16]: No mention of either Silverlight or .NET on Windows
Здравствуйте, hattab, Вы писали:
H>При использование специализированных менеджеров памяти можно вообще избежать фрагментирования кучи
Не бесплатно.
H>Зачем ужиматься до 2Gb, когда позволяется 3Gb на 32-битных системах и 4Gb на 64?
Я в курсе. Принципиально проблему это не решает.
H> Разумеется, я не отрицаю явного преимущества 64-битного адресного пространства, но нужно это далеко не всем.
Но это не означает, что не нужно почти никому, как ты утверждаешь.
И где там проблемы GC? Фиксация на глобальных событиях/сигналах без отписки при любой технологии управления памятью приведет к утечке. Потому что проблема логическая, а не технологическая.
Здравствуйте, TK, Вы писали:
TK>А вот в .net удаление любого объекта из дерева, это хождение по граблям — все ссылки владеющие, а WeakReference без "внешней поддержки" использовать практически нельзя.
А зачем убивать объект, когда на него остались ссылки? Чтобы потом воевать с помершими ссылками?
TK>"Если кто-то подписался на event, значит это ему нужно." — получается паттерн "буратино вырос". после этого, истинный владелец "буратин" будет ломать голову над тем, как их всех родить обратно. Weak Event в том-же WPF это как раз и следствие того, что "проблемы циклических ссылок в .Net нет".
Какая связь между циклическими ссылками и weak подпиской?
Re[2]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Sclis, Вы писали:
S>Возможно Microsoft ожидает заметных перемен в компьютерных железках.
Нет.
S>При таком раскладе надо успевать выдать свежую версию и ОС и средств разработки и это надо делать паралелльно. Нет времени ждать, пока .Net устаканится под новые реалии
Нет никакой необходимости чего то устаканивать с дотнетом — рантайм обновляется очень редко и понемногу.
S>, она слишком мнолитна и громоздка для резких поворотов.
Аргументируй. Потому что, по факту, как раз нативные решения проигрывают по скорости адаптации к изменениям.
S>Представьте, если у кого-то уже дозревает до рыночной кондиции технология хранения данных со скоростью процессорного кэша и емкостью + себестоимость + энегронезависимость HDD. Как это повлияет на поведение крупных производителей софта ?!
Сперва ты расскажи, что такого придется кардинально менять при этом в рантайме дотнета.
S>>При таком раскладе надо успевать выдать свежую версию и ОС и средств разработки и это надо делать паралелльно. Нет времени ждать, пока .Net устаканится под новые реалии
НС>Нет никакой необходимости чего то устаканивать с дотнетом — рантайм обновляется очень редко и понемногу.
а почему тогда в текущей версии windows phone используется урезанный Compact Framework, а не нормальный .net? я так понял они не успели его полноценно на АРм портировать
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Аргументируй. Потому что, по факту, как раз нативные решения проигрывают по скорости адаптации к изменениям.
По факту не проигрывают, так как не припомню таких событий чтобы сравнить для менеджед, а натив
вполне неплохо адаптируем, например тот же apple уже несколько раз менял аппаратуру.
Re[4]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>а почему тогда в текущей версии windows phone используется урезанный Compact Framework, а не нормальный .net? я так понял они не успели его полноценно на АРм портировать
FR>В утечке памяти на платформе с GC и переходе на практически ручное управление чтобы ее избежать.
Это не утечка памяти. Проблема ничем не отличается от
class A { }
class B { public A A { get; set; } }
// ...
A a = new A();
B b = new B() { A = a };
и сохранения ссылки на b, поэтому какой-нибудь "альтернативный" GC тут ничем не поможет. Костыли по ссылки — защита от отдельных одарённых личностей, что не могут усвоить правило "подписался — отпишись".
Re[16]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Скорее всего просто подстраховываются на случай, если большая часть этих 4ГБ уже занята.
А когда хотят 8, то подстраховываются на случай, если пользователь забил большую часть этих восьми? Когда пишут "рекомендуем исспользовать 64-х битную версию" от чего подстраховываются?
ВВ>И откуда дефицит памяти на 32-битах?
А вы с чем спорите-то? С надписями на дисках от производителей?
Кстати, Крайтек уже пишет в Спортлото, что на приставки надо 8G ставить. Это минимум, говорят.
Здравствуйте, Sinix, Вы писали:
FR>>В утечке памяти на платформе с GC и переходе на практически ручное управление чтобы ее избежать. S>Это не утечка памяти. Проблема ничем не отличается от
Да это понятно конечно.
Но память все равно бестолково зависает.
S>и сохранения ссылки на b, поэтому какой-нибудь "альтернативный" GC тут ничем не поможет. Костыли по ссылки — защита от отдельных одарённых личностей, что не могут усвоить правило "подписался — отпишись".
Это и есть ручное управление.
Утрированно и RAII в C++ и GC это только защита от отдельных одаренных личностей не способных на каждый malloc вызвать free
Re[17]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H> Разумеется, я не отрицаю явного преимущества 64-битного адресного пространства, но нужно это далеко не всем.
НС> Но это не означает, что не нужно почти никому, как ты утверждаешь.
Здравствуйте, FR, Вы писали:
FR>Да это понятно конечно. FR>Но память все равно бестолково зависает.
+1
S>>и сохранения ссылки на b, поэтому какой-нибудь "альтернативный" GC тут ничем не поможет. Костыли по ссылки — защита от отдельных одарённых личностей, что не могут усвоить правило "подписался — отпишись". FR>Это и есть ручное управление.
Неа, тут скорее явное освобождение ресурсов
На самом деле по ссылке городят тонну лишнего кода, для ленивого события более чем достаточно WeakList<T> (пишется самостоятельно за 5 минут).
Ну, а если делать всерьёз, то надо целиком имитировать реализацию multicast delegate — сделать immutable-тип, внутри которого — WeakReference<TDelegate>[] + (опционально) хелпер, что будет обновлять поле, используя Modify-CompareExchange loop (см пример). Поскольку снаружи всё выглядит как обычный event EventHandler MyEvent, для клиентского кода разницы никакой.
Делается 1 раз... и нигде не используется за практической ненадобностью. У меня где-то валяется набросок трёхлетней давности, не пригодился пока.
FR>Утрированно и RAII в C++ и GC это только защита от отдельных одаренных личностей не способных на каждый malloc вызвать free
Угу
Здравствуйте, FR, Вы писали:
НС>>Слабые ссылки это у тебя ручное управление? Вобщем, все как и предполагалось, слышал звон ...
FR>Так полного автомата нет
Что значит нет? Слабые ссылки работают полностью автоматически.
FR>, а полуавтоматы и без GC доступны, те же shared_ptr/weak_ptr
Ага, с проблемами на циклах и перформансе.
Re[4]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>а почему тогда в текущей версии windows phone используется урезанный Compact Framework, а не нормальный .net?
Потому же, почему вообще CF существует — куцые ресурсы и необходимость беречь батарейку.
Re[4]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Ночной Смотрящий, Вы писали:
FR>>Так полного автомата нет
НС>Что значит нет? Слабые ссылки работают полностью автоматически.
Так и shared_ptr/weak_ptr тоже полностью автоматически работают, после того как их расставил.
FR>>, а полуавтоматы и без GC доступны, те же shared_ptr/weak_ptr
НС>Ага, с проблемами на циклах и перформансе.
Тут вопрос сложный в контексте GUI который обычно однопоточный и не требует особого быстродействия
(кроме самого нижнего уровня) но зато очень любит чтобы не было внезапных остановок даже на короткое
время. С этим как раз у ref count все гораздо лучше чем у GC.
Re[5]: No mention of either Silverlight or .NET on Windows 8
