Здравствуйте, MxMsk, Вы писали:
MM> H>Ты не правильно понимаешь. Нет никаких бубнов Достаточно владение контролом передать компоненту в том scope, из которого он тебе потребуется
MM> Не пытайся вылезти на этом "непонимании". Что такое Owner в VCL, я пока что помню. Только проблему это не фига не решает.
Да нет же, решает Я тебе код с хуком показал. Там о существовании хука не знает вообще никто. Ни кнопка, ни какие либо глобальные компоненты. Более того, хук не является компонентом и у него нет owner'а, но он тем не менее помрет, когда помрет кнопка. Угадай, как решается
MM> Что ты будешь делать, если у тебя не будет скопа, которому передавать владение, м?
Что значит не будет scope? Как может не быть области видимости? Как бы там ни было, у тебя всегда есть глобальный Application, отдай ему, если сам запутался А воообще, мне как-то странно обсуждать сферовакуумные выдумки без конкретных примеров
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, MxMsk, Вы писали:
H>>>Ты не правильно понимаешь. Нет никаких бубнов Достаточно владение контролом передать компоненту в том scope, из которого он тебе потребуется MM>>Не пытайся вылезти на этом "непонимании". Что такое Owner в VCL, я пока что помню. Только проблему это не фига не решает. Что ты будешь делать, если у тебя не будет скопа, которому передавать владение, м? Впрочем, уже как-то стремно становится. Мы опускаемся до обсуждения очевиднейших траблов языков без GC. Для чего нужно объяснять убогость этих решений, мне не очень ясно
FR>GC это очень хорошо спору нет. FR>Но практика показывает что не всякий и не везде. FR>GUI на управляемых языках все-таки гораздо тормознее на практике чем даже когда-то считавшиеся не шустрым нативный VCL.
"Гораздо" — это насколько? Цифрами и методикой измерений не поделитесь?
FR>>GC это очень хорошо спору нет. FR>>Но практика показывает что не всякий и не везде. FR>>GUI на управляемых языках все-таки гораздо тормознее на практике чем даже когда-то считавшиеся не шустрым нативный VCL.
КБ>"Гораздо" — это насколько? Цифрами и методикой измерений не поделитесь?
Чисто субъективно.
Цифры возможно найдутся у разработчиков Evernote.
Re[12]: No mention of either Silverlight or .NET on Windows
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Константин Б., Вы писали:
FR>>>GC это очень хорошо спору нет. FR>>>Но практика показывает что не всякий и не везде. FR>>>GUI на управляемых языках все-таки гораздо тормознее на практике чем даже когда-то считавшиеся не шустрым нативный VCL.
КБ>>"Гораздо" — это насколько? Цифрами и методикой измерений не поделитесь?
FR>Чисто субъективно.
А зачем вы писали "практика показывает", "на практике", когда вам всего лишь кажется?
FR>Цифры возможно найдутся у разработчиков Evernote.
Ну вот пусть они вместо вас в дискуссии и участвуют.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Константин Б., Вы писали: FR>>>Чисто субъективно. КБ>>А зачем вы писали "практика показывает", "на практике", когда вам всего лишь кажется?
FR>Моя практика это показывает. Она конечно субъективна, но совпадает с практиками большого количества FR>людей.
Ну так расскажите о своей практике поподробнее. Что, с чем и как сравнивали?
Методику подсчета "большинства людей" оставим за кадром. Художественное преувеличение и все такое.
FR>>>Цифры возможно найдутся у разработчиков Evernote. КБ>>Ну вот пусть они вместо вас в дискуссии и участвуют. FR>Не вижу ваших цифр, думаю вам стоит применить ваши только что установленные правила в первую очередь FR>к себе.
Правило тут простое: Кто сомнительные тезисы приводит — тот пусть их цифрами и подкрепляет.
Здравствуйте, Константин Б., Вы писали:
КБ>Ну так расскажите о своей практике поподробнее. Что, с чем и как сравнивали?
Нет не расскажу, я выразил свое мнение, не нравится опровергайте с цифрами, не хотите
опровергать высказываете свое.
Жаль только VS версией 2010 испортили
КБ>Методику подсчета "большинства людей" оставим за кадром. Художественное преувеличение и все такое.
Не надо передергивать, про большинство людей я не говорил.
FR>>Не вижу ваших цифр, думаю вам стоит применить ваши только что установленные правила в первую очередь FR>>к себе.
КБ>Правило тут простое: Кто сомнительные тезисы приводит — тот пусть их цифрами и подкрепляет.
Здравствуйте, hattab, Вы писали:
MM>> Что ты будешь делать, если у тебя не будет скопа, которому передавать владение, м? H>Что значит не будет scope? Как может не быть области видимости? Как бы там ни было, у тебя всегда есть глобальный Application, отдай ему, если сам запутался А воообще, мне как-то странно обсуждать сферовакуумные выдумки без конкретных примеров
Ты понимаешь, что означает слово "автоматически"? Именно об автоматическом слежении за ресурсами изначально шла речь. И именно с возможностью полноценного автоматического управления в нативных языках я и спорю. То, что ты предлагаешь — это не автоматически. Твой вариант с Application только демонстрирует проблему. Либо контролы, либо Application — среднего не дано — в этом проблема.
Почему-то TK не торопится с примером "отсоединения от ламбд"
Re[11]: No mention of either Silverlight or .NET on Windows
Здравствуйте, hattab, Вы писали:
H>Ну а если разработчик дает возможность использовать 32-битные версии при наличии 64-битных
Ну вот на текущей работе софт вообще managed, и запускается и на 32-х и на 64-х битах. На 32-х оно в принципе работает, но на некоторых приложениях под большой нагрузкой может вылететь OutOfMemoryException. На 64 битах этой проблемы нет.
Здравствуйте, MxMsk, Вы писали:
MM>>>Далеко не всегда. В WPF, например, время жизни контрола вообще трудоуловимое в силу таких фичей, как шаблоны данных. Что касается "удаления из лямбд", то как же он сам это сделает? TK>>В WPF никак. А в С++ есть готовые решения. MM>Я про эти решения и спрашиваю.
Для С++ есть "слабые" указатели которые уходят в 0 при явном удалении объекта (а не тогда, когда GC в голову придет). Есть сигналы которые могут автоматически разрывать связь с объектом при его удалении (не надо думать кто и куда подписал удаляемый объект и как его потом отписывать). Для всего этого написаны нормальные библиотеки которые позволяют выразит намерения разработчика без лишнего шума.
В итоге, проблема циклических ссылок стоит не так явно как то может казаться. Проблема циклических ссылок есть скорее в .net — каждая подписка на событие это фактически разделение владения объекта с источником событий. А учитывая, что детерминированного освобождения объектов нет (а в GUI как раз обычно все детерминировано) — это лишняя головная боль.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, MxMsk, Вы писали:
MM>А если хук понадобиться мне после того, как "кнопка решит отдать концы"? Давай повторю, что мне хочется. Мне хочется, чтобы объекты могли собираться тогда, когда GUI фреймворк о них не имеет понятия. Когда они "в пределах видимости" GUI, т.е. находятся в визуальном дереве, ну или там в списке Components — то всё легко. А если я их временно оттуда выкидываю, что тогда? А если не выкину, но контрол понадобиться мне после удаления его родителя? Тут и начинаются танцы с бубнами и ручное управление.
Не надо путать враппер для кнопки (OkButton) и ресурс связанный с данной кнопкой (окно).
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, MxMsk, Вы писали:
MM> MM>> Что ты будешь делать, если у тебя не будет скопа, которому передавать владение, м?
MM> H>Что значит не будет scope? Как может не быть области видимости? Как бы там ни было, у тебя всегда есть глобальный Application, отдай ему, если сам запутался А воообще, мне как-то странно обсуждать сферовакуумные выдумки без конкретных примеров
MM> Ты понимаешь, что означает слово "автоматически"?
Я понимаю, а ты похоже нет Если я не прикладываю усилий для слежением за жизнью контролов, значит VCL делает это за меня т.е. автоматически. На уровне библиотеки. Все просто
MM> Именно об автоматическом слежении за ресурсами изначально шла речь.
...применительно к гуевым библиотекам. Тебе цитату привести?
MM> И именно с возможностью полноценного автоматического управления в нативных языках я и спорю.
А мы не о языках, мы о гуевых библиотеках Ладно, цитирую:
Мы же про возможность автоматического управления ресурсами и памятью для GUI библиотек на C++
MM> То, что ты предлагаешь — это не автоматически. Твой вариант с Application только демонстрирует проблему. Либо контролы, либо Application — среднего не дано — в этом проблема.
Да нет же, это автоматически Просто эта автоматизация осуществлена на уровне библиотеки, а не языка. А пример с Application был призван продемонстрировать тебе, что если ты заблудился в scope — есть универсальное решение . И вообще странная претензия: либо контролы, либо Application... Вообще-то любому компоненту можно передать права владения.
MM> Почему-то TK не торопится с примером "отсоединения от ламбд"
Так и ты что-то не торопишься с примерами хитрых манипуляций с контролами, где тебе требуется передача прав владения. Лишь одно пожелание: будешь медитировать, старайся ближе к реальности
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H>Ну а если разработчик дает возможность использовать 32-битные версии при наличии 64-битных
НС> Ну вот на текущей работе софт вообще managed, и запускается и на 32-х и на 64-х битах. На 32-х оно в принципе работает, но на некоторых приложениях под большой нагрузкой может вылететь OutOfMemoryException. На 64 битах этой проблемы нет.
Менеджед такой менеджед? Недетерминированность высвобождения ресурсов во всей красе, я правильно понимаю? Ок. Для избавления от подобного рода проблем использование 64 бит является оправданным. Остается лишь порадоваться, что явление это не массовое
Здравствуйте, hattab, Вы писали:
H>Менеджед такой менеджед? Недетерминированность высвобождения ресурсов во всей красе, я правильно понимаю?
Нет, не правильно. Просто интенсивная работа с большими объемами памяти и, как следствие, фрагментация. Я ведь не зря писал про нехватку address space, а не памяти.
H>Ок. Для избавления от подобного рода проблем использование 64 бит является оправданным. Остается лишь порадоваться, что явление это не массовое
Смотря где. На рынке серверных приложений вполне массовое. Да и решарперы всякие огребают по полной программе.
Re[13]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H>Менеджед такой менеджед? Недетерминированность высвобождения ресурсов во всей красе, я правильно понимаю?
НС> Нет, не правильно. Просто интенсивная работа с большими объемами памяти и, как следствие, фрагментация. Я ведь не зря писал про нехватку address space, а не памяти.
Пардон, а как же дефрагментация хипа? Или куски такие большие что для них дефрагментация не выполняется? А пулы проблему не решают?
НС> H>Ок. Для избавления от подобного рода проблем использование 64 бит является оправданным. Остается лишь порадоваться, что явление это не массовое
НС> Смотря где. На рынке серверных приложений вполне массовое. Да и решарперы всякие огребают по полной программе.
Натив позволяет этого избежать выбрав политику управления памятью под задачу
Здравствуйте, hattab, Вы писали:
H>А что нибудь из недевелоперского?
Топовые игры. ИМХО 32 поддерживаются для того, чтоб оно хоть как-то запустилось и там, но во всяких Фаркраях2 и прочих последних Сталкерах 64 — хардли рекоммендед и всё такое. Как только манагеры дадут отмашку, что рынок на 32 можно забить, так сразу будет 64 only. Хотя может я и ошибаюсь, хотелось-бы коментариев кого-нибуть из гейм-дева.
Я тебе код с хуком показал. Там о существовании хука не знает вообще никто. Ни кнопка, ни какие либо глобальные компоненты. Более того, хук не является компонентом и у него нет owner'а, но он тем не менее помрет, когда помрет кнопка. Угадай, как решается 
А воообще, мне как-то странно обсуждать сферовакуумные выдумки без конкретных примеров 
