Здравствуйте, iyura, Вы писали:
MC>>Здравствуйте, iyura, Вы писали: I>>>Понимаю. У нас весь сырбор разгорелся из-за того, что в управляемых средах не особенно следует обращать внимание на очистку ресурсов — придет GC и все сделает. Так я как раз о том, что не все
MC>>Непонятно, откуда взялось заблуждение, что GC должен выполнять очистку всех ресурсов. Сборка мусора реализована для единственного ресурса — памяти. За остальными по-прежнему должен следить сам программист.
I>Я согласен, что это заблуждение. Но оно опасно тем, что порождает иллюзии. Это из личного опыта — пришел на проект, которым раньше занимались люди слепо верящие в GC. Об IDispose, using и.п. они не заботились. И что самое хреновое — это все как-то работало
Индусы, наверное, какие-то?
I>Правда никого не заботило то, что при старте приложения при одном открытом окошке с маленькис списком 70Мб памяти было откушено. Мда...сумбурно получается. Короче, программист воспитаный на неуправляемой среде пишет качественнее
I>Вот и я о том же. А ведь деструктор это
I>- централизованное место, где происходит разрушение объекта ( не будем вдаваться в рантайм и тонкости компиляторов) I>- четкие правила, когда деструктор вызывается.
Это не относится к управляемой среде.
I>Как сладствие — более четкое управление ресурсами
Здравствуйте, gandjustas, Вы писали:
H>>Получение IUnknown от INonCOMInterface не делает последний COM'ом. G>В этом ты неправ. Уже десять раз тебе сказали.
Да мне тут много чего говорили... Всему верить чтоль
Здравствуйте, gandjustas, Вы писали:
B>>>Я валяюсь, а ответьте коллега, что в Вашем понятии COM Object, чем таким особенным он обладает? H>>Не нужно повторяться в вопросах, я на это уже отвечал: помимо IUnknown, это совместимые типы и соглашения о вызовах (но с соглашениями не все однозначно, как с типами).
G>Ссылку на источник сего откровения.
Да какую ссылку тебе нужно? Роджерсона (Inside COM) можешь почитать. Только если ты сам выводы делать не будешь, то не найдешь в книге выводов.
Здравствуйте, _d_m_, Вы писали:
___>>>>>Спорить в разрезе Дельфи-ДотНет и приводить в качестве аргумента какие-то пропадающие конфиги — это либо — в споре все средства хороши, либо проблемы с неадекватным восприятием реальности.
H>>>>Никто в таком разрезе не спорит. Я уже пояснял, кажется. Ну а конфиги... Ну ведь есть прблема, чего ее отрицать-то?
___>>>Какая проблема? Что отрицать? Что у кого-то там пропали конфиги по вине юзеров и что это проблема ДотНет, а мол дельфины и без конфигов работают — ну это ахинея.
H>>Проблема в практике использования таких конфигов. Заметь, я уже неоднократно писал, что можно и все правильно сделать.
___>А причем здесь Дельфи или ДотНет?
Рекомендуемый/пропогандируемый/самый популярный/(подставь сам) подход может быть не идеальным. Если следуя ему легко сотворить корягу -- она таки будет сотворена (вспомним нападки на Delphi за то, что малограмотные кодеры размещали всю логику в обработчиках формы. Казалось бы, причем тут Delphi?). Еще пояснения нужны?
Здравствуйте, _d_m_, Вы писали:
H>>>>Аналогии не катят. Ибо ты не пробовал проектировать Абрамс и ИС немецкой ЖД.
___>>>Жаль, что для тебя не катят. Но я проектировал многое другое, и знаком с другими проектами и эти проекты мне приходилось/приходится обслуживать. Плюс, есть опыт эксплуатации этих продуктов многими другими людьми. А теперь подумай про автомобили — аналогии катят.
H>> И я проектировал многое другое, и знаком с другими проектами, и прочее и прочее. Что мне теперь можно сказать про .Net, мол, никто не застрахован от неудачных решений? (для тех кто не понял: это шутка)
___>Сказать то все что угодно можно. Можно в принципе и против ветра ссать, если нравится так. Ведь никтож не запрещает.
Здравствуйте, DOOM, Вы писали:
DOO>>>Кстати спор у вас ни о чем. Директива inline в C только рекомендует компилятору делать inline, реально он сам и так все поймет. Дак вот — в дельфи не было этой рекомендательной директивы, но был inline — просто целиком управляемый компилятором.
K>>Вот мне и хотелось проверить, выполняет ли он инлайнинг в принципе. DOO>Выполняет. Когда-то специально копался.
Некоторые операции она таки инлайнит. Например, операция получения интерфейса от объекта может быть выполнена без обращения к методу GetInterface.
K>>Для этого я и попросил автора скомпилить тот код с высшими настройками оптимизации. Ибо я не могу придумать другого более очевидного кандидата на инлайнинг. Если у вас есть какие-то идеи на эту тему — welcome
DOO>Эх. Не достать мне сейчас Дельфи, чтобы продемонстрировать
Эти функции не будут инлайниться ни при каких настройках, ибо смысла нет.
Здравствуйте, OCTAGRAM, Вы писали:
>> OCT>gandjustas пишет: >>> > Я больше всего работал в Delphi7 — большенитсво впечатлений оттуда. >> OCT>Delphi7 — это 2001й год. С тем же успехом можно ругать Windows за >> OCT>дырявость, а IE — за отсутствие табов. >> >> Версии после Delphi 7 — с поддержкой .NET. Многие новшества, принесенные >> в язык — заслуга .NET OCT>Ну эта тенденция давно уже. Раньше вот за счёт COM появлялось.
В Delphi, не то с 2006, не то с 2005 есть class helpers появившиеся в .Net 3.5, как методы расширения (так кажется)
Здравствуйте, hattab, Вы писали:
>>> Версии после Delphi 7 — с поддержкой .NET. Многие новшества, принесенные >>> в язык — заслуга .NET OCT>>Ну эта тенденция давно уже. Раньше вот за счёт COM появлялось.
H>В Delphi, не то с 2006, не то с 2005 есть class helpers появившиеся в .Net 3.5, как методы расширения (так кажется)
Helper classes were introduced in Delphi 8 as a way of binding the VCL to the .Net framework. To quote the Delphi help: “Class helpers are a way to extend a class without using inheritance. A class helper simply introduces a wider scope for the compiler to use when resolving identifiers.”
Здравствуйте, Mamut, Вы писали:
M>>>INonCOMInterface наследуется от IUnknown. Более того (или, вернее, поэтому), INonCOMInterface может быть приведено к IUnknown. Более того, наследование от IUnknown означает, что для INonCOMInterface автоматически становятся доступны три базовых COM-метода: AddRef, Release и QueryInterface (потому что они реализованы в IUnknown)
H>>Интерфейс есть декларация. Интерфейс ничего не реализует. Получение IUnknown от INonCOMInterface не делает последний COM'ом. Рассматривать несколько методов INonCOMInterface в отрыве от всего интерфейса -- идеологически неверно, ибо интерфейс есть единица неделимая. Какими словами это еще объяснять
M>Объясни следующее:
M>1. Чем отличаются две следующие строчки: M>
M>В первом случае MyClass наследуется от TObject. Во втором? M>Если во втором — это тоже наследование, то: M>- если родитель является TObject, является ли наследник TObject? M>- если родитель является COM-объектом, является ли наследник COM-объектом?
Если объект реализует хоть один COM-интерфейс, он является COM-объектом. Помимо этого, он может реализовывать интерфейсы не являющиеся COM-совместимыми. Само по себе наследование интерфейса от COM-совместимого не делает его COM-совместимым т.к., еще раз говорю, интерфейс нельзя рассматривать по частям, это неделимая единица.
M>2. Interface Keyword
M>Ключевое слово Interface является всего лишь способом получить множественное наследование от абстрактных классов.
M>
M>When implementing an interface, you must implementQueryInterface, _AddRef and _Release standard interface methods, unless you base your class on one that already has these implemented, such as TInterfacedObject.
M>При реализации интерфейсы вы обязаны реализовать стандартные методы QueryInterface, _AddRef and _Release, если ваш класс не будет создан на основе класса, который их уже реализует (примером такого класса может служить TInterfacedObject)
Зачем ты мне эти простыни цитируешь, думаешь я не знаю об этом?
Здравствуйте, hattab, Вы писали:
H>>>Получение IUnknown от INonCOMInterface не делает последний COM'ом. G>>В этом ты неправ. Уже десять раз тебе сказали.
H>Да мне тут много чего говорили... Всему верить чтоль
M>>>В первом случае MyClass наследуется от TObject. Во втором? M>>>Если во втором — это тоже наследование, то: M>>>- если родитель является TObject, является ли наследник TObject? M>>>- если родитель является COM-объектом, является ли наследник COM-объектом?
kuj>>Все верно только следует понимать, что интерфейс может быть унаследован только интерфейсом, а класс реализует (implement) интерфейс. Но это так.. вопрос терминологии.
M>ну это да. В дельфи интерфейсами банальные абстрактные классы обозваны
Вообще-то в Delphi интерфейсы, это интерфейсы, а абстрактные классы, это абстрактные классы (терминология C++ не катит). Абстрактные классы обозначаются по другому:
TAbstarctClass = Class Abstract (TObject)
...
End;
H>Если объект реализует хоть один COM-интерфейс, он является COM-объектом. Помимо этого, он может реализовывать интерфейсы не являющиеся COM-совместимыми. Само по себе наследование интерфейса от COM-совместимого не делает его COM-совместимым т.к., еще раз говорю, интерфейс нельзя рассматривать по частям, это неделимая единица.
Интерфейс IUnknown обяхывает меня реализовать в последубщих наследуемых классах QueryInterface, _AddRef и _Release — да или нет?
H>Зачем ты мне эти простыни цитируешь, думаешь я не знаю об этом?
То есть я все равно обязан реализовать методы QueryInterface, _AddRef и _Release или отнаследоваться от TInterfacedObject? Вне зависимости от того, отнаслеуюсь я своим классом от IUnknown или от INonCOMInterface? Если да, то я получу COM-Объект, потому что наличие этих методов, емнип, яляется необходимым и достаточным условием для сохдания COM-объекта
Здравствуйте, OCTAGRAM, Вы писали:
>> У Delphi 2006 офигительно быстрый менеджер памяти.
OCT>Я помню, один раз хорошо сэкономил своей команде время на кодинг, OCT>дописав type String = String[255] в начале, без этого не проходило по OCT>времени. А время в разы отличается, как ни крути.
Здравствуйте, OCTAGRAM, Вы писали:
>> OCT>Delphi 2007? >> >> C 2005.
>> OCT>тоже 2007? в 2006 не помню такого >> >> С 2005
OCT>А это точно не .NET всё?
M>>ну это да. В дельфи интерфейсами банальные абстрактные классы обозваны
H>Вообще-то в Delphi интерфейсы, это интерфейсы, а абстрактные классы, это абстрактные классы (терминология C++ не катит). Абстрактные классы обозначаются по другому: H>
H>TAbstarctClass = Class Abstract (TObject)
H> ...
H>End;
H>
Чем интерфейс в Дельфи отличается от абстрактного класса?
Здравствуйте, kuj, Вы писали:
>>>> Версии после Delphi 7 — с поддержкой .NET. Многие новшества, принесенные >>>> в язык — заслуга .NET OCT>>>Ну эта тенденция давно уже. Раньше вот за счёт COM появлялось.
H>>В Delphi, не то с 2006, не то с 2005 есть class helpers появившиеся в .Net 3.5, как методы расширения (так кажется)
kuj>
kuj>Helper classes were introduced in Delphi 8 as a way of binding the VCL to the .Net framework. To quote the Delphi help: “Class helpers are a way to extend a class without using inheritance. A class helper simply introduces a wider scope for the compiler to use when resolving identifiers.”
Я имел ввиду нативные версии, восьмерка была чисто .Net.
Здравствуйте, Mamut, Вы писали:
H>>Если объект реализует хоть один COM-интерфейс, он является COM-объектом. Помимо этого, он может реализовывать интерфейсы не являющиеся COM-совместимыми. Само по себе наследование интерфейса от COM-совместимого не делает его COM-совместимым т.к., еще раз говорю, интерфейс нельзя рассматривать по частям, это неделимая единица.
M>Интерфейс IUnknown обяхывает меня реализовать в последубщих наследуемых классах QueryInterface, _AddRef и _Release — да или нет?
Если ты определяешь класс реализующий IUnknown и ни один из его предков не реализует IUnknown, ты будешь обязан эти методы реализовать.
H>>Зачем ты мне эти простыни цитируешь, думаешь я не знаю об этом?
M>То есть я все равно обязан реализовать методы QueryInterface, _AddRef и _Release или отнаследоваться от TInterfacedObject? Вне зависимости от того, отнаслеуюсь я своим классом от IUnknown или от INonCOMInterface? Если да, то я получу COM-Объект, потому что наличие этих методов, емнип, яляется необходимым и достаточным условием для сохдания COM-объекта
Ответ да. Ты получишь COM-объект. Но интерфейс INonCOMObject так и не будет COM-интерфейсом, ведь дергая методы _AddRef, _Release, QueryInterface ты работаешь только с IUnknown.
Здравствуйте, Mamut, Вы писали:
M>>>ну это да. В дельфи интерфейсами банальные абстрактные классы обозваны
H>>Вообще-то в Delphi интерфейсы, это интерфейсы, а абстрактные классы, это абстрактные классы (терминология C++ не катит). Абстрактные классы обозначаются по другому: H>>
H>>TAbstarctClass = Class Abstract (TObject)
H>> ...
H>>End;
H>>
M>Чем интерфейс в Дельфи отличается от абстрактного класса?
Интерфейс -- чистая декларация. Абстрактный класс -- класс, объекты которого нельзя создать (хотя в 2006 есть глюк, и такие объекты создать можно). При этом, абстрактный класс, может иметь любые поля/свойства/методы (не обязательно абстрактые).
M>>То есть я все равно обязан реализовать методы QueryInterface, _AddRef и _Release или отнаследоваться от TInterfacedObject? Вне зависимости от того, отнаслеуюсь я своим классом от IUnknown или от INonCOMInterface? Если да, то я получу COM-Объект, потому что наличие этих методов, емнип, яляется необходимым и достаточным условием для сохдания COM-объекта
H>Ответ да. Ты получишь COM-объект. Но интерфейс INonCOMObject так и не будет COM-интерфейсом, ведь дергая методы _AddRef, _Release, QueryInterface ты работаешь только с IUnknown.
И я проектировал многое другое, и знаком с другими проектами, и прочее и прочее. Что мне теперь можно сказать про .Net, мол, никто не застрахован от неудачных решений? 
