Здравствуйте, hattab, Вы писали:
MSS>>Недостатки: отсутствие толковой оптимизации кода, что делает его медленнее Явы и Шарпа. Отвратительно уродский слой работы с базами данных под названием BDE. Проблемы с обращением к компонентам OLE Automation.
H>Оптимизация кода не идеальная. Но этот код не медленнее Java/C# (для себя полгода назад писал расчетный (примитивный расчет с использование типов Double) бенч на C# и Delphi. Писал объективно, ибо для себя. Разница почти 2 раза в пользу Delphi).
Это значит только, что писать под .NET не умеешь.
В целом ряде случаев .NET дает более высокую производительность за счет более тонкой оптимизации под целевой процессор (компиляция из байт-кода в машинный производится непосредственно там, где он будет выполняться).
H>Примеры приводить не буду, пенисометрия мне не интересна. Если угодно, пусть это останется моим голословным утверждением по аналогии с уже звучавшими от опонентов. BDE это конечно кошмар, но уже давно есть и ADO, и DbExpress (который, к слову, и является основной рекомендуемой техникой). Проблем с OLE Automation не испытываю со времен пятерки.
Угу, в .NET LINQ for SQL, а в Delphi все пользуются низкоуровневыми средствами. Нашел чем гордиться.
Здравствуйте, Mr.Cat, Вы писали:
H>>Ты давай расскажи, как .Net будет разруливать это. Мне ждать ответа, или ты слил?
MC>Похоже, Вы не в курсе про принципы работы GC. Для начала про один из вариантов можно почитать здесь
(с примерами реализации). Идея в том, чтобы отделить граф "доступных" объектов от графа "недоступных", несмотря на наличие взаимных ссылок у "недоступных" объектов.
Вероятно, имеет смысл уточнить: мы говорим не об объектах, а об интерфейсах. Для интерфейсов существует только один способ GC -- подсчет ссылок.
H>ADO, DbExpress (основная) и целая куча нативных движков начиная от Oracle и заканчивая самыми примитивными. У тебя, как всегда, информация из 98-2000 Хватит уже лаять в след давно ушедшему поезду.
Так и есть. Именно потому в 98-2000 люди шарахались от Дельфей.
BDE — аналог Jet из Access. Для своей родной файловой БД неплох, но обращения к внешним SQL источникам там идут через механизм attached table, который, как я понимаю, откачивает почти всю выборку из внешнего SQL в таблицу во временной "родной" БД, и потом листает именно ее.
Дрянь. И BDE дрянь, и использование Access для SQL Server и Oracle тоже дрянь.
Здравствуйте, hattab, Вы писали: H>Вероятно, имеет смысл уточнить: мы говорим не об объектах, а об интерфейсах. Для интерфейсов существует только один способ GC -- подсчет ссылок.
Вы под интерфейсом понимаете COM-интерфейс? Тогда ХЗ, возможно, Вы и правы. Не знаю, как работает GC для оберток COM-объектов.
Здравствуйте, gandjustas, Вы писали:
H>>>>>>Дано: Интерфейс (именно интерфейс) родитель имеющий список дочерних элементов, так же интерфейсов (это обязательно). Работоспособность дочерних элементов зависит от жизни родителя (т.е. родитель не может умереть пока жив хоть один дочерний элемент). Соответственно дочерние элементы имеют ссылку на интерфейс-родитель. Тут возникает проблема: имеем перекрестные (взаимные) ссылки. Решение должно учитывать тот факт, что пользователь родительского объекта не знает о его заморочках и будет использовать стандартную практику работы с интерфейсными переменными. Предлагай решение без подсчета ссылок. Э>>>>>Вот здесь и проявятся плюсы .NET — на Delphi (да и на любой другой платформе без GC) надо писать все эти AddRef, Release (не факт, что не забудешь вызвать их в нужном месте), а на .Net, Java etc. все происходит автоматом. H>>>>Ну расскажи, как автоматом разрулятся взаимные ссылки
G>>>Не боись, действительно все это разруливается.
H>>Очень хочется послушать, как это будет сделано. Жду.
G>Если дочерний объект ссылается на родителя, то он увеличивает ему счетчик сылок. Тогда родительский объект будет жить пока живут дочерние. Соответственно если объект создает дочерние, то он и должен их удалять. Это вообще COM-объект так должен работать. G>.NET объекты выставленные как COM так и работают
Я еще раз уточняю: речь идет об интерфейсах. А менять условие задачи, для подгона под ответ -- это моветон. Интерфейс-родитель не может удалить дочерние т.к. они должны быть удалены только в момент смерти самого родителя, а он не может умереть пока жив хоть один дочерний. В свою очередь, дочерние интерфейсы сами имеют ссылку на родителя. Плюс, на дочерние интерфейсы (да и на родительский) имеются ссылки со стороны приложения.
Эта задача не высосона из пальца. Не так давно я эту ситуацию разруливал именно благодаря наличию ручного управления счетчиком ссылок. Сразу добавлю, просчета в проектировании тут нет
Здравствуйте, Mr.Cat, Вы писали:
H>>Вероятно, имеет смысл уточнить: мы говорим не об объектах, а об интерфейсах. Для интерфейсов существует только один способ GC -- подсчет ссылок.
MC>Вы под интерфейсом понимаете COM-интерфейс? Тогда ХЗ, возможно, Вы и правы. Не знаю, как работает GC для оберток COM-объектов.
Хм... Ну пусть будет COM-объект. Хотя в Delphi интерфейсы могут иметь не только COM-объекты.
Здравствуйте, kuj, Вы писали:
kuj>Это значит только, что писать под .NET не умеешь.
kuj>В целом ряде случаев
"Какой ряд вы называете целым?"
kuj> .NET дает более высокую производительность за счет более тонкой оптимизации под целевой процессор (компиляция из байт-кода в машинный производится непосредственно там, где он будет выполняться).
У JIT-компиляторов оптимизация получается неважная — потому что важно обеспечить быструю компиляцию.
Здравствуйте, Maxim S. Shatskih, Вы писали:
H>>ADO, DbExpress (основная) и целая куча нативных движков начиная от Oracle и заканчивая самыми примитивными. У тебя, как всегда, информация из 98-2000 Хватит уже лаять в след давно ушедшему поезду.
MSS>Так и есть. Именно потому в 98-2000 люди шарахались от Дельфей.
Пятерка (99 год) одна из самых популярных версий. Шестерка (2001) первая версия с возможностью кросс-платформенного программирования (CLX проекты были полностью совместимы с Kylix). Исход начался позднее, даже позднее выхода семерки. Восьмая версия (чисто-.Net) самая неудачная.
MSS>BDE — аналог Jet из Access. Для своей родной файловой БД неплох, но обращения к внешним SQL источникам там идут через механизм attached table, который, как я понимаю, откачивает почти всю выборку из внешнего SQL в таблицу во временной "родной" БД, и потом листает именно ее.
Кажется, BDE появился раньше Jet (хотя тут могу ошибаться)
MSS>Дрянь. И BDE дрянь, и использование Access для SQL Server и Oracle тоже дрянь.
BDE -- дрянь, не спорю. Прямой (и высокоуровневый) доступ -- рулез. А DbExpress обеспечивает, практически, и то и другое
Здравствуйте, hattab, Вы писали:
H>Я еще раз уточняю: речь идет об интерфейсах. А менять условие задачи, для подгона под ответ -- это моветон. Интерфейс-родитель не может удалить дочерние т.к. они должны быть удалены только в момент смерти самого родителя, а он не может умереть пока жив хоть один дочерний. В свою очередь, дочерние интерфейсы сами имеют ссылку на родителя. Плюс, на дочерние интерфейсы (да и на родительский) имеются ссылки со стороны приложения.
Теперь понял. Ты сам показал еще один (даже два) недостаток делфи
В .NET и Java интерфейс — просто контракт, ссылка на интерфейс (переменная типа интнрфейс) подчиняется темже правилам, что и объекты. У интерфейсов нету никаких ссылок и считать их не надо. GC нормально разруливает любые цикличесике зависимотси.
В делфи интерфейсы обладают семантикой COM-объектов (это само по себе недостаток — номер раз). Хотя делфи и поддерживает более-менее автоматизированный подсчет ссылок, но есть задачи, в которых подсчет ссылок приходится писать руками которые иллюстрирует твоя задача (недостаток номер два).
В .NET и Java такого вообще нет из-за другой семантики интерфейсов. А при работе с .NET объектами через COM таких проблема не возникает потому что сборщик мусора нормально разруливает подобные ситуации.
H>Эта задача не высосона из пальца. Не так давно я эту ситуацию разруливал именно благодаря наличию ручного управления счетчиком ссылок. Сразу добавлю, просчета в проектировании тут нет
Коненчо не высосана из пальца. Просчет тут именно в использовании делфи.
Здравствуйте, Эдик, Вы писали:
H>>Речь об интерфейсах.
Э>Это ничего не меняет — за каждой ссылкой на интерфейс стоит объект и по ссылке на интерфейс GC доберется до объекта.
Гхм. А если этот интерфейс от нативного COM-объекта?
Здравствуйте, gandjustas, Вы писали:
H>>Я еще раз уточняю: речь идет об интерфейсах. А менять условие задачи, для подгона под ответ -- это моветон. Интерфейс-родитель не может удалить дочерние т.к. они должны быть удалены только в момент смерти самого родителя, а он не может умереть пока жив хоть один дочерний. В свою очередь, дочерние интерфейсы сами имеют ссылку на родителя. Плюс, на дочерние интерфейсы (да и на родительский) имеются ссылки со стороны приложения. G>Теперь понял. Ты сам показал еще один (даже два) недостаток делфи G>В .NET и Java интерфейс — просто контракт, ссылка на интерфейс (переменная типа интнрфейс) подчиняется темже правилам, что и объекты. У интерфейсов нету никаких ссылок и считать их не надо. GC нормально разруливает любые цикличесике зависимотси. G>В делфи интерфейсы обладают семантикой COM-объектов (это само по себе недостаток — номер раз). Хотя делфи и поддерживает более-менее автоматизированный подсчет ссылок, но есть задачи, в которых подсчет ссылок приходится писать руками которые иллюстрирует твоя задача (недостаток номер два).
Справедливости ради, ручной подсчет делается только в интерфейсе-родителе (изменяется метод Release). Мои пользователи об этом даже не подозревают и пользуются обычными приемами при работе.
G>В .NET и Java такого вообще нет из-за другой семантики интерфейсов. А при работе с .NET объектами через COM таких проблема не возникает потому что сборщик мусора нормально разруливает подобные ситуации.
Ок. Кого он убьет раньше, родителя или дочерний интерфейс? Далее. Если тебе придется работать с COM-интерфейсами и будет аналогичная ситуация, ты без подсчета ссылок усядешься в лужу.
H>>Эта задача не высосона из пальца. Не так давно я эту ситуацию разруливал именно благодаря наличию ручного управления счетчиком ссылок. Сразу добавлю, просчета в проектировании тут нет G>Коненчо не высосана из пальца. Просчет тут именно в использовании делфи.
Меня устраивает нативная среда с внятным, полуавтоматическим GC (таким, какой он есть) и развитым языком
Здравствуйте, hattab, Вы писали:
H>Гхм. А если этот интерфейс от нативного COM-объекта?
Я, честно говоря, с COM-объектами из .NET не работал, но вот что пишет Э. Троелсен («C# и платформа .NET»):
«…всю черновую работу берет на себя модуль RCW (run-time callable wrapper). Он производит кэширование всех ссылок на интерфейсы и в нужный момент производит вызов метода Release() для сервера COM, на который больше нет активных ссылок со стороны клиентов .NET. В результате клиентам .NET нет необходимости явно производить вызовы методов AddRef(), Release() или QueryInterface()».
И там же:
«…RCW создавать вручную не нужно — это произодится автоматически…»
То есть, если я правильно понял, при добавлении в проект ссылки на COM-тип автоматически создается обертка для него, которая и занимается всей черновой работой.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
G>>В .NET и Java такого вообще нет из-за другой семантики интерфейсов. А при работе с .NET объектами через COM таких проблема не возникает потому что сборщик мусора нормально разруливает подобные ситуации. H>Ок. Кого он убьет раньше, родителя или дочерний интерфейс? Далее. Если тебе придется работать с COM-интерфейсами и будет аналогичная ситуация, ты без подсчета ссылок усядешься в лужу.
Ну это ты зря. тебе же дали ссылки на механизм работы GC. CG сам отлично справляется с такой ситуацией.
Вкратце будет так: когда родитель и дочерние объекты станут недостижимым умрут все.
H>Меня устраивает нативная среда с внятным, полуавтоматическим GC (таким, какой он есть) и развитым языком
Просто ты в других мало работал.
Когда у нас на работе пришла девушка я заставлял её писать Linq запросы вместо SQL, хотя она сильно сопростивлялась и говорила что написать JOIN на SQL гораздо легче. Ниче, через месяц привыкла, теперь даже желания не возникает SQLи писать
Здравствуйте, Эдик, Вы писали:
Э>То есть, если я правильно понял, при добавлении в проект ссылки на COM-тип автоматически создается обертка для него, которая и занимается всей черновой работой.
Вроде того.
Здравствуйте, Эдик, Вы писали:
Э>Я, честно говоря, с COM-объектами из .NET не работал, но вот что пишет Э. Троелсен («C# и платформа .NET»): Э>
Э>«…всю черновую работу берет на себя модуль RCW (run-time callable wrapper). Он производит кэширование всех ссылок на интерфейсы и в нужный момент производит вызов метода Release() для сервера COM, на который больше нет активных ссылок со стороны клиентов .NET. В результате клиентам .NET нет необходимости явно производить вызовы методов AddRef(), Release() или QueryInterface()».
Э>И там же: Э>
Э>«…RCW создавать вручную не нужно — это произодится автоматически…»
Э>То есть, если я правильно понял, при добавлении в проект ссылки на COM-тип автоматически создается обертка для него, которая и занимается всей черновой работой.
Delphi тоже сама ссылки считает Но дело в том, что взаимозависимость уже есть, по условию задачи. Т.е. два COM-интерфейса ссылаются друг на друга. Кого и главное, когда убивать?
Нашел чем гордиться.
Хватит уже лаять в след давно ушедшему поезду.
