Здравствуйте, _d_m_, Вы писали:
MC>>>Предполагается, что Dispose технически корректно освобождает ресурсы.
I>>Вот как-то не складывается у меня с этим. Не спорю, скорее по незнанию\отсутствию опыта. Но я бы хотел сазать, что, например в С++ такие вещи идеологически чище. Чего стоят деструкторы в шарпе — читаешь документацию и сразу выпить хочется
___>Выпить хочется — это по другой причине. А деструкторов в шарпе — нет. Есть финализаторы — а это огромная разница. Читать Рихтера.
Здравствуйте, Mamut, Вы писали:
kuj>>>....из чего следует, что вызов INonCOMObject._AddRef есть вызов метода INonCOMObject интерфейса, а не IUnknown интерфейса... Понял наконец?
H>>Вообще то, от реализации зависит... Но даже если рассмотреть твой вариант, какая разница, чей это вызов в вопросе COM не COM?
M>Объект, реализующий AddRef, Release и QueryInterface является чем?
COM-совместимым. Но! Это не делает интерфейс INonCOMObject COM-совместимым. Еще раз: интерфейс это целое, делить его нельзя (говорить, что три метода у нас совместимы, и потому совместим он весь). То, что COM сможет использовать три его метода, не дает ему права считаться COM-совместимым.
Здравствуйте, Mamut, Вы писали:
M>>>Чем интерфейс в Дельфи отличается от абстрактного класса?
H>>Интерфейс -- чистая декларация. Абстрактный класс -- класс, объекты которого нельзя создать (хотя в 2006 есть глюк, и такие объекты создать можно). При этом, абстрактный класс, может иметь любые поля/свойства/методы (не обязательно абстрактые).
M>В общем, разницы никакой за двумя важными исключениями:
Да ты чего??? Абстрактный класс может иметь реализованные методы, может иметь поля. В то время, как интерфейс только декларирует набор методов.
M>1. Interface позволяет множественное наследование M>2. В классах, наследуемых от Interface СOM-совместимые методы гвоздями прибиваются в самое начало vtable для обеспечения COM-совместимости. Таким образом, любой класс, наследуемый (в цепочке любой длины) от IUnknown будет COM-объектом, потому что у него будет как минимум три COM-совместимых метода: AddRef, Rekease и QueryInterface
M>Все эти извращения нужны только для одного — облегчить создание COM-объектов в Delphi
Терминология твоя просто жуть. Классы не наследуются от интерфейсов, они их реализуют. Наличие в классе методов _AddRef, _Release, QueryInterface не делает его автоматически реализующим IUnknown.
M>>>Должен ли я в MyClass реализовывать QueryInterface, _AddRef и _Release. Если нет, то почему?
H>>Должен, ибо это декларирует IUnknown от которого ты наследовал свой интерфейс. Тут есть еще очень важный момент. Если ты продекларируешь в классе реализуцию только одного интерфейса (MyInterface), от таких объектов нельзя будет получить IUnknown. Для получения IUnknown нужно декларировать реализацию обоих интерфейсов (или иметь предком класс реализующий IUnknown).
M>Что за бредятина? В чем тогда смысл объявления M>
M>MyInterface : Interface(IUnknown)
M>
M>?
Смысл в том, что описываешь НОВЫЙ интерфейс расширяя его методами предка. Если ты реализуешь в классе MyInterface, но не продекларируешь, что класс реализует IUnknown, последний от класса получить не удастся (при условии, что ни один из предков не реализует IUnknown). Если не веришь мне, сам попробуй.
Здравствуйте, _d_m_, Вы писали:
H>>>>Проблема в практике использования таких конфигов. Заметь, я уже неоднократно писал, что можно и все правильно сделать.
___>>>А причем здесь Дельфи или ДотНет?
H>>Рекомендуемый/пропогандируемый/самый популярный/(подставь сам) подход может быть не идеальным. Если следуя ему легко сотворить корягу -- она таки будет сотворена (вспомним нападки на Delphi за то, что малограмотные кодеры размещали всю логику в обработчиках формы. Казалось бы, причем тут Delphi?). Еще пояснения нужны?
___>Не помню таких нападок. Т.е. ты считаешь, что использование конфигов есть потенциальный путь сотворить корягу, и что это недостаток ДотНет?
Нападки были не в этой ветке, я говорю обобщая те, что слышал. Я не только так считаю, я еще и пример приводил
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Mamut, Вы писали:
kuj>>>>....из чего следует, что вызов INonCOMObject._AddRef есть вызов метода INonCOMObject интерфейса, а не IUnknown интерфейса... Понял наконец?
H>>>Вообще то, от реализации зависит... Но даже если рассмотреть твой вариант, какая разница, чей это вызов в вопросе COM не COM?
M>>Объект, реализующий AddRef, Release и QueryInterface является чем?
H>COM-совместимым. Но! Это не делает интерфейс INonCOMObject COM-совместимым. Еще раз: интерфейс это целое, делить его нельзя (говорить, что три метода у нас совместимы, и потому совместим он весь). То, что COM сможет использовать три его метода, не дает ему права считаться COM-совместимым.
И какая разница? Зачем нам сферовакуумный интерфейс? Если конкретный класс, его реализующий, все равно становится COM-объектом? С этого и начинался весь сыр-бор, емнип — есть ли в Дельфи не-COM интерфейсы:
Каждый объект, реализующий интерфейс преобретает семантику COM-объекта. То есть при использовании становится фактически COM-объектом.
Поэтому итнерфейсы в Delphi — именно COM-интерфейсы.
Можешь не спорить, это факт.
Любой класс, реализующий твой якобы не-COM интерфейс вдруг автоматом становится COM-объектом. Это как это так это?
То есть пусть даже все методы в новом интерфейсе будут несовместимыми с COM, как миниум три метода у него всегда будут COM-совместимыми, что автоматом делает интерфейс — сюрприз-сюрприз — совместимым с COM
M>>>>Должен ли я в MyClass реализовывать QueryInterface, _AddRef и _Release. Если нет, то почему?
H>>>Должен, ибо это декларирует IUnknown от которого ты наследовал свой интерфейс. Тут есть еще очень важный момент. Если ты продекларируешь в классе реализуцию только одного интерфейса (MyInterface), от таких объектов нельзя будет получить IUnknown. Для получения IUnknown нужно декларировать реализацию обоих интерфейсов (или иметь предком класс реализующий IUnknown).
M>>Что за бредятина? В чем тогда смысл объявления M>>
M>>MyInterface : Interface(IUnknown)
M>>
M>>?
H>Смысл в том, что описываешь НОВЫЙ интерфейс расширяя его методами предка.
Но при этом методы предка в новом интерфейсе остаются?
H>Если ты реализуешь в классе MyInterface, но не продекларируешь, что класс реализует IUnknown, последний от класса получить не удастся (при условии, что ни один из предков не реализует IUnknown). Если не веришь мне, сам попробуй.
Это как это так это? Борланд решил похерить все принципы наследования для интерфейсов??
// IUnknown декларирует _AddRef, _Release, QueryInterface
IntermediateInterface : Interface(IUnknown)
begin// в дополнение к трем предыдущим методам мы добавляемfunction GetData() : AnsiString
end
FinalInterface : Interface(IntermediateInterface)
begin// в дополнение к четырем предыдущимprocedure DoSmth();
end
MyClass: Class(FinalInterface)
begin// какие методы должен реализовать MyClass?end
Здравствуйте, hattab, Вы писали:
kuj>>>>....из чего следует, что вызов INonCOMObject._AddRef есть вызов метода INonCOMObject интерфейса, а не IUnknown интерфейса... Понял наконец?
H>>>Вообще то, от реализации зависит... Но даже если рассмотреть твой вариант, какая разница, чей это вызов в вопросе COM не COM?
M>>Объект, реализующий AddRef, Release и QueryInterface является чем?
H>COM-совместимым. Но! Это не делает интерфейс INonCOMObject COM-совместимым. Еще раз: интерфейс это целое, делить его нельзя (говорить, что три метода у нас совместимы, и потому совместим он весь). То, что COM сможет использовать три его метода, не дает ему права считаться COM-совместимым.
Дает вообще-то. Хаттаб ты утомил своим невежеством. Тебе три или четыре человека русским языком втолковывают, а ты продолжаешь слепо строить свою стену непонимания.
Здравствуйте, Mr.Cat, Вы писали:
kuj>>Вообще-то есть... http://msdn.microsoft.com/en-us/library/66x5fx1b.aspx
MC>Один фиг — финализаторы. Просто почему-то разработчикам языка C# захотелось использовать для них C++-like синтаксис.
Видимо старались придерживаться C++ alike синтаксиса... В VB деструктор-финализатор это именно Finalize(), afaik.
Здравствуйте, OCTAGRAM, Вы писали:
>> А теперь объясните, при чем здесь стек. OCT>При том, что http://en.wikipedia.org/wiki/Funarg_problem OCT>Я не против концепции, я против конкретной реализации.
Т.е. Вам не нравится существующая реализация .NET FW потому что для решения funarg problem в ней путем неявного оборачивания замыканий и yield-методов в классы "хакается" стековая архитектура, вместо того, чтобы изначально использовать механизмы, не приводящие к funarg problem?
Попробую ответить.
.NET развивался как платформа, изначально поддерживающая 3 языка: MC++, C# и VB.NET. Все эти языки изначально не имели funarg problem, можно даже сказать, что на дизайн этих языков стек оказал определенное влияние. Поэтому и в реализации FW был использован стек и стекоориентированный IL. Сейчас смысла что-либо переделывать никакого нет. Функциональные языки не являются основным направлением развития платформы: F# — пока только эксперементальная игрушка, Nemerle — пожалуй, еще не так широко известен и используется, чтобы стать мейнстримом в .NET. Мейнстрим в .NET — это императивные языки. Функциональные возможности, добавленные в C# не делают его функциональным языком, о том, что функция является first-class object говорить нельзя. Поэтому реализация сохранения контекста вызова в виде небольшого "хака" стека — вполне уместна. Т.е. к императивной основе .NET, полагающейся на стек "сбоку" приделали функциональные возможности и реализовали их в рамках имеющихся средств вот и все. Когда функциональность войдет в мейнстрим — вот тогда и полюбуемся на всякие functional language runtime и иже с ними.
Здравствуйте, Mamut, Вы писали:
kuj>>>>>....из чего следует, что вызов INonCOMObject._AddRef есть вызов метода INonCOMObject интерфейса, а не IUnknown интерфейса... Понял наконец?
H>>>>Вообще то, от реализации зависит... Но даже если рассмотреть твой вариант, какая разница, чей это вызов в вопросе COM не COM?
M>>>Объект, реализующий AddRef, Release и QueryInterface является чем?
H>>COM-совместимым. Но! Это не делает интерфейс INonCOMObject COM-совместимым. Еще раз: интерфейс это целое, делить его нельзя (говорить, что три метода у нас совместимы, и потому совместим он весь). То, что COM сможет использовать три его метода, не дает ему права считаться COM-совместимым.
M>И какая разница? Зачем нам сферовакуумный интерфейс? Если конкретный класс, его реализующий, все равно становится COM-объектом? С этого и начинался весь сыр-бор, емнип — есть ли в Дельфи не-COM интерфейсы:
M>
M>Каждый объект, реализующий интерфейс преобретает семантику COM-объекта. То есть при использовании становится фактически COM-объектом.
M>Поэтому итнерфейсы в Delphi — именно COM-интерфейсы.
M>Можешь не спорить, это факт.
M>Любой класс, реализующий твой якобы не-COM интерфейс вдруг автоматом становится COM-объектом. Это как это так это?
Мамут, ты запарил, ей богу... Передай, пожалуйста, по DCOM, динамический массив из анси-строк. Если при этом у тебя проблем с маршалингом не возникнет, я съем свои носки, а ты сможешь сказать, что в Delphi все интерфейсы COM-совместимы. Еще раз тебе повторяю, INonCOMObject не будет являться COM-совместимым вне зависимости от того, реализует класс методы IUnknown или нет.
M>То есть пусть даже все методы в новом интерфейсе будут несовместимыми с COM, как миниум три метода у него всегда будут COM-совместимыми, что автоматом делает интерфейс — сюрприз-сюрприз — совместимым с COM
Я тебе уже наглядно продемонстрировал, что можно сделать класс недекларирующий реализацию IUnknown, но реализующий INonCOMObject (наследованый от IUnknown), и от объектов этого класса невозможно будет получить IUnknown. Думай.
Здравствуйте, Mamut, Вы писали:
H>>Смысл в том, что описываешь НОВЫЙ интерфейс расширяя его методами предка.
M>Но при этом методы предка в новом интерфейсе остаются?
Разумеется. Подумай вот над чем: можешь ли ты у интерфейса узнать, кто его предок. Не можешь (ну, не считая фокусов с RTTI). Думай дальше.
H>>Если ты реализуешь в классе MyInterface, но не продекларируешь, что класс реализует IUnknown, последний от класса получить не удастся (при условии, что ни один из предков не реализует IUnknown). Если не веришь мне, сам попробуй.
M>Это как это так это? Борланд решил похерить все принципы наследования для интерфейсов??
Прикол в том, что наследование интерфейсов это просто расширении деклараций потомков, декларациями предков. Это не ООП наследование, где потомок можно привести к любому из предков. Для интерфейсов еще важно, как их будет реализовывать класс.
M>
M>// IUnknown декларирует _AddRef, _Release, QueryInterface
M>IntermediateInterface : Interface(IUnknown)
M>begin
M>// в дополнение к трем предыдущим методам мы добавляем
M>function GetData() : AnsiString
M>end
M>FinalInterface : Interface(IntermediateInterface)
M>begin
M>// в дополнение к четырем предыдущим
M>procedure DoSmth();
M>end
M>MyClass: Class(FinalInterface)
M>begin
M> // какие методы должен реализовать MyClass?
M>end
M>
Смотря от чего наследуется. Если наследуется от класса реализующего IUnknown, то только методы GetData и DoSmth; Если от обычного класса, то реализовать необходимо все 5 методов. Вот еще посмотри:
// Объект реализующий только IMyInterface
TMyObject = Class(TObject, IMyInterface)
...
End;
// Объект реализующий, и IUnknown, и IMyInterface
TMyObject2 = Class(TObject, IUnknown, IMyInterface)
...
End;
В этом примере, от объекта класса TMyObject ты не сможешь получить IUnknown несмотря на то, что IMyInterface наследован от него.
Здравствуйте, kuj, Вы писали:
kuj>>>>>....из чего следует, что вызов INonCOMObject._AddRef есть вызов метода INonCOMObject интерфейса, а не IUnknown интерфейса... Понял наконец?
H>>>>Вообще то, от реализации зависит... Но даже если рассмотреть твой вариант, какая разница, чей это вызов в вопросе COM не COM?
M>>>Объект, реализующий AddRef, Release и QueryInterface является чем?
H>>COM-совместимым. Но! Это не делает интерфейс INonCOMObject COM-совместимым. Еще раз: интерфейс это целое, делить его нельзя (говорить, что три метода у нас совместимы, и потому совместим он весь). То, что COM сможет использовать три его метода, не дает ему права считаться COM-совместимым.
kuj>Дает вообще-то. Хаттаб ты утомил своим невежеством. Тебе три или четыре человека русским языком втолковывают, а ты продолжаешь слепо строить свою стену непонимания.
Вообще-то не дает Я Мамуту развернуто ответил, прочитай.
Здравствуйте, hattab, Вы писали:
H>INonCOMObject расширяет IUnknown. Говоря о INonCONObject мы говорим не только о трех методах. INonCOMObject не может являться COM-интерфейсом если имеет декларации несовместимые с требованиями COM. Это так сложно понять?
А какие декларации несовместимы с COM? Ссыллку на авторитетный источник, лучше MSDN. Иначе вся твоя болтовня — фуфло.
Здравствуйте, hattab, Вы писали:
H>Терминология твоя просто жуть. Классы не наследуются от интерфейсов, они их реализуют. Наличие в классе методов _AddRef, _Release, QueryInterface не делает его автоматически реализующим IUnknown.
С чего ты взял?
COM можно писать на C (обычном, без плюсов). Там вообще нет понятия интерфейса. Так ДОСТАТОЧНО реализовать _AddRef, _Release, QueryInterface
Здравствуйте, hattab, Вы писали:
H>Мамут, ты запарил, ей богу... Передай, пожалуйста, по DCOM, динамический массив из анси-строк. Если при этом у тебя проблем с маршалингом не возникнет, я съем свои носки, а ты сможешь сказать, что в Delphi все интерфейсы COM-совместимы. Еще раз тебе повторяю, INonCOMObject не будет являться COM-совместимым вне зависимости от того, реализует класс методы IUnknown или нет.
Ты свсем тупой чтоли? Даже не понимаешь разнице между COM и DCOM? Кстати я тебе пост на эту тему кидал.
H>Я тебе уже наглядно продемонстрировал, что можно сделать класс недекларирующий реализацию IUnknown, но реализующий INonCOMObject (наследованый от IUnknown), и от объектов этого класса невозможно будет получить IUnknown. Думай.
Еще одна бага в делфи?
В других языках (в C++ к примеру) при таком раскладе можно получить IUnknown.
Re[8]: наши менеджеры памяти самые менеджеристые менеджеры п
Здравствуйте, OCTAGRAM, Вы писали:
OCT>Я помню, один раз хорошо сэкономил своей команде время на кодинг, OCT>дописав type String = String[255] в начале, без этого не проходило по OCT>времени. А время в разы отличается, как ни крути.
Я бы очень удивился если бы было иначе. Особенно если используются конструкции типа Str:= Str + BlaBlaBla;
Здравствуйте, gandjustas, Вы писали:
H>>INonCOMObject расширяет IUnknown. Говоря о INonCONObject мы говорим не только о трех методах. INonCOMObject не может являться COM-интерфейсом если имеет декларации несовместимые с требованиями COM. Это так сложно понять? G>А какие декларации несовместимы с COM? Ссыллку на авторитетный источник, лучше MSDN. Иначе вся твоя болтовня — фуфло.
Здравствуйте, gandjustas, Вы писали:
H>>Терминология твоя просто жуть. Классы не наследуются от интерфейсов, они их реализуют. Наличие в классе методов _AddRef, _Release, QueryInterface не делает его автоматически реализующим IUnknown.
G>С чего ты взял?
G>COM можно писать на C (обычном, без плюсов). Там вообще нет понятия интерфейса. Так ДОСТАТОЧНО реализовать _AddRef, _Release, QueryInterface
Абстрактный класс может иметь реализованные методы, может иметь поля. В то время, как интерфейс только декларирует набор методов.
Я Мамуту развернуто ответил, прочитай.
