Здравствуйте, Константин Б., Вы писали:
КБ> FR>Все очень давно украдено до нас, практически все живые сейчас C++ GUI библиотеки автоматически управляют ресурсами.
КБ> Например в Qt да?
Здравствуйте, MxMsk, Вы писали:
MM> Они это могут делать только в рамках себя самих. Допустим, я беру ссылку на какой-нить контрол, а потому выкидываю этот контрол из родительского. Кто им управит?
В VCL понятия владения и принадлежности разделены. Смена парента не изменяет владельца.
Здравствуйте, hattab, Вы писали:
MM>> Они это могут делать только в рамках себя самих. Допустим, я беру ссылку на какой-нить контрол, а потому выкидываю этот контрол из родительского. Кто им управит? H>В VCL понятия владения и принадлежности разделены. Смена парента не изменяет владельца.
Не означает ли это, что мудрая VCL возьмет да грохнет мой контрол, когда я того не хочу?
Re[13]: No mention of either Silverlight or .NET on Windows
Здравствуйте, MxMsk, Вы писали:
MM> L>> Последний SQL Server и SharePoint
MM> H>А что нибудь из недевелоперского?
MM> SharePoint и есть "недевелоперское".
Он более девелоперский, чем эндюзерский Хотя со стороны МС это вообще чистая политика, в свете перевода своих ОС на 64-бита и отказа от 32 бит. То есть, тут, как раз, все очень даже ожидаемо
Здравствуйте, MxMsk, Вы писали:
FR>>Новый родитель. MM>Его нет. Я выдернул контрол из дерева, а потом передал его еще в кучу разных лямбд, которые вызовутся через определенное время, и возможно вернут его в дерево, а возможно нет. Как здесь автоматически что-то соберется?
Держать список сирот и прибивать на выходе из цикла обработки сообщений.
MM>Или упомянутый уже Data Binding. Допустим у меня есть объект, который я задал как источник данных в неизвестном числе контролов. Теперь все эти контролы удаляются из дерева. Должен ли их источник данных быть уничтожен? А если на него сослался какой-то другой объект вне дерева? Как GUI об этом узнает?
Тут не спорю GC рулит, особенно если нужно управлять объектами вне конкретной библиотеки.
Но те же библиотеки обычно представляют механизмы (тот же подсчет ссылок например) позволяющие взять под свое управление
внешние объекты.
Здравствуйте, MxMsk, Вы писали:
MM> MM>> Они это могут делать только в рамках себя самих. Допустим, я беру ссылку на какой-нить контрол, а потому выкидываю этот контрол из родительского. Кто им управит?
MM> H>В VCL понятия владения и принадлежности разделены. Смена парента не изменяет владельца.
MM> Не означает ли это, что мудрая VCL возьмет да грохнет мой контрол, когда я того не хочу?
Здравствуйте, hattab, Вы писали:
MM>> H>В VCL понятия владения и принадлежности разделены. Смена парента не изменяет владельца. MM>> Не означает ли это, что мудрая VCL возьмет да грохнет мой контрол, когда я того не хочу? H>Не означает. Она позволяет управлять владением.
Вернее, там, где она не может справиться с владением, она возлагает эту рутину на разработчика.
Здравствуйте, MxMsk, Вы писали:
MM>Его нет. Я выдернул контрол из дерева, а потом передал его еще в кучу разных лямбд, которые вызовутся через определенное время, и возможно вернут его в дерево, а возможно нет. Как здесь автоматически что-то соберется?
На С++ все очень даже соберется — достаточно сказать объекту delete и он сам отпишется от всех событий и удалит себя из всех лямбд. Тем более, что для UI контролов обычно всегда понятно что "тут он нужен", а "тут уже больше не нужен". А вот с managed кодом — солнце придется закатывать "вручную"
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
MM>>Его нет. Я выдернул контрол из дерева, а потом передал его еще в кучу разных лямбд, которые вызовутся через определенное время, и возможно вернут его в дерево, а возможно нет. Как здесь автоматически что-то соберется? TK>На С++ все очень даже соберется — достаточно сказать объекту delete и он сам отпишется от всех событий и удалит себя из всех лямбд. Тем более, что для UI контролов обычно всегда понятно что "тут он нужен", а "тут уже больше не нужен". А вот с managed кодом — солнце придется закатывать "вручную"
Далеко не всегда. В WPF, например, время жизни контрола вообще трудоуловимое в силу таких фичей, как шаблоны данных. Что касается "удаления из лямбд", то как же он сам это сделает?
Здравствуйте, MxMsk, Вы писали:
MM>Далеко не всегда. В WPF, например, время жизни контрола вообще трудоуловимое в силу таких фичей, как шаблоны данных. Что касается "удаления из лямбд", то как же он сам это сделает?
В WPF никак. А в С++ есть готовые решения.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
MM>>Далеко не всегда. В WPF, например, время жизни контрола вообще трудоуловимое в силу таких фичей, как шаблоны данных. Что касается "удаления из лямбд", то как же он сам это сделает? TK>В WPF никак. А в С++ есть готовые решения.
Я про эти решения и спрашиваю.
Здравствуйте, MxMsk, Вы писали:
MM> H>Не означает. Она позволяет управлять владением.
MM> Вернее, там, где она не может справиться с владением, она возлагает эту рутину на разработчика.
Что за бред? Тебе хоть раз приходилось вручную управлять владением в VCL? Компонентная модель дельфей позволяет писать такой код:
THook.Create(OkButton);
и не беспокоиться о том кто, как и когда убъет хук поставленный на кнопку. Но хук будет прибит, как только кнопка решит отдать концы.
Здравствуйте, hattab, Вы писали:
MM>> H>Не означает. Она позволяет управлять владением. MM>> Вернее, там, где она не может справиться с владением, она возлагает эту рутину на разработчика. H>Что за бред? Тебе хоть раз приходилось вручную управлять владением в VCL? Компонентная модель дельфей позволяет писать такой код: H> THook.Create(OkButton); H>и не беспокоиться о том кто, как и когда убъет хук поставленный на кнопку. Но хук будет прибит, как только кнопка решит отдать концы.
А если хук понадобиться мне после того, как "кнопка решит отдать концы"? Давай повторю, что мне хочется. Мне хочется, чтобы объекты могли собираться тогда, когда GUI фреймворк о них не имеет понятия. Когда они "в пределах видимости" GUI, т.е. находятся в визуальном дереве, ну или там в списке Components — то всё легко. А если я их временно оттуда выкидываю, что тогда? А если не выкину, но контрол понадобиться мне после удаления его родителя? Тут и начинаются танцы с бубнами и ручное управление.
Здравствуйте, MxMsk, Вы писали:
MM> H>Что за бред? Тебе хоть раз приходилось вручную управлять владением в VCL? Компонентная модель дельфей позволяет писать такой код: MM> H> THook.Create(OkButton); MM> H>и не беспокоиться о том кто, как и когда убъет хук поставленный на кнопку. Но хук будет прибит, как только кнопка решит отдать концы.
MM> А если хук понадобиться мне после того, как "кнопка решит отдать концы"? Давай повторю, что мне хочется. Мне хочется, чтобы объекты могли собираться тогда, когда GUI фреймворк о них не имеет понятия. Когда они "в пределах видимости" GUI, т.е. находятся в визуальном дереве, ну или там в списке Components — то всё легко. А если я их временно оттуда выкидываю, что тогда? А если не выкину, но контрол понадобиться мне после удаления его родителя? Тут и начинаются танцы с бубнами и ручное управление.
Ты путаешь владение и принадлежность. Визуальное дерево это не владение, это принадлежность.
Здравствуйте, hattab, Вы писали:
MM>> А если хук понадобиться мне после того, как "кнопка решит отдать концы"? Давай повторю, что мне хочется. Мне хочется, чтобы объекты могли собираться тогда, когда GUI фреймворк о них не имеет понятия. Когда они "в пределах видимости" GUI, т.е. находятся в визуальном дереве, ну или там в списке Components — то всё легко. А если я их временно оттуда выкидываю, что тогда? А если не выкину, но контрол понадобиться мне после удаления его родителя? Тут и начинаются танцы с бубнами и ручное управление. H>Ты путаешь владение и принадлежность. Визуальное дерево это не владение, это принадлежность.
Хорошо. С бубнами я так понимаю, ты не споришь.
Здравствуйте, MxMsk, Вы писали:
MM> MM>> А если хук понадобиться мне после того, как "кнопка решит отдать концы"? Давай повторю, что мне хочется. Мне хочется, чтобы объекты могли собираться тогда, когда GUI фреймворк о них не имеет понятия. Когда они "в пределах видимости" GUI, т.е. находятся в визуальном дереве, ну или там в списке Components — то всё легко. А если я их временно оттуда выкидываю, что тогда? А если не выкину, но контрол понадобиться мне после удаления его родителя? Тут и начинаются танцы с бубнами и ручное управление.
MM> H>Ты путаешь владение и принадлежность. Визуальное дерево это не владение, это принадлежность.
MM> Хорошо. С бубнами я так понимаю, ты не споришь.
Ты не правильно понимаешь. Нет никаких бубнов Достаточно владение контролом передать компоненту в том scope, из которого он тебе потребуется
Здравствуйте, hattab, Вы писали:
MM>> Хорошо. С бубнами я так понимаю, ты не споришь. H>Ты не правильно понимаешь. Нет никаких бубнов Достаточно владение контролом передать компоненту в том scope, из которого он тебе потребуется
Не пытайся вылезти на этом "непонимании". Что такое Owner в VCL, я пока что помню. Только проблему это не фига не решает. Что ты будешь делать, если у тебя не будет скопа, которому передавать владение, м? Впрочем, уже как-то стремно становится. Мы опускаемся до обсуждения очевиднейших траблов языков без GC. Для чего нужно объяснять убогость этих решений, мне не очень ясно
P.S. Забавно. На всякий случай я поискал в Гугле, и первая же ссылка вывела меня на трэд, в котором я же и отвечал когда-то про Parent/Owner.
Здравствуйте, MxMsk, Вы писали:
H>>Ты не правильно понимаешь. Нет никаких бубнов Достаточно владение контролом передать компоненту в том scope, из которого он тебе потребуется MM>Не пытайся вылезти на этом "непонимании". Что такое Owner в VCL, я пока что помню. Только проблему это не фига не решает. Что ты будешь делать, если у тебя не будет скопа, которому передавать владение, м? Впрочем, уже как-то стремно становится. Мы опускаемся до обсуждения очевиднейших траблов языков без GC. Для чего нужно объяснять убогость этих решений, мне не очень ясно
GC это очень хорошо спору нет.
Но практика показывает что не всякий и не везде.
GUI на управляемых языках все-таки гораздо тормознее на практике чем даже когда-то считавшиеся не шустрым нативный VCL.
Re[12]: No mention of either Silverlight or .NET on Windows
Хотя со стороны МС это вообще чистая политика, в свете перевода своих ОС на 64-бита и отказа от 32 бит. То есть, тут, как раз, все очень даже ожидаемо 
