Здравствуйте, hattab, Вы писали:
H>Я имел ввиду нативные версии, восьмерка была чисто .Net.
Различие в том, что в .NET каждый extension method указывает какой именно класс он расширяет. Таким образом методы, расширяющие разные классы, можно поместить в один класс.
public static class MyExtensions
{
public static int WordCount(this String str)
{
...
}
public static int DaysToNewYear(this DateTime date)
{
...
}
...
}
Здравствуйте, hattab, Вы писали:
H>Ответ да. Ты получишь COM-объект. Но интерфейс INonCOMObject так и не будет COM-интерфейсом, ведь дергая методы _AddRef, _Release, QueryInterface ты работаешь только с IUnknown.
Нет, ты работаешь с INonCOMObject, а не с IUnknown. INonCOMObject наследует эти методы от IUnknown.
Здравствуйте, hattab, Вы писали:
H>>>Не нужно повторяться в вопросах, я на это уже отвечал: помимо IUnknown, это совместимые типы и соглашения о вызовах (но с соглашениями не все однозначно, как с типами). G>>Ссылку на источник сего откровения. H>Да какую ссылку тебе нужно? Роджерсона (Inside COM) можешь почитать. Только если ты сам выводы делать не будешь, то не найдешь в книге выводов.
Ты действительно думаешь что твои выводы правильнее того что сказал человек, который COM придумал?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Mamut, Вы писали: M>>То есть я все равно обязан реализовать методы QueryInterface, _AddRef и _Release или отнаследоваться от TInterfacedObject? Вне зависимости от того, отнаслеуюсь я своим классом от IUnknown или от INonCOMInterface? Если да, то я получу COM-Объект, потому что наличие этих методов, емнип, яляется необходимым и достаточным условием для сохдания COM-объекта
H>Ответ да. Ты получишь COM-объект. Но интерфейс INonCOMObject так и не будет COM-интерфейсом, ведь дергая методы _AddRef, _Release, QueryInterface ты работаешь только с IUnknown.
Изучай ООП. Наследование моделирует отношение "является", то есть если INonCOMObject наследует IUnknown, то он в каком-то смысле является IUnknown. IUnknown в свою очередь является COM интерфейсом, следовательно INonCOMObject является COM интерфейсом.
Или для тебя ООП тоже не авторитет?
Здравствуйте, Mamut, Вы писали:
M>>>То есть я все равно обязан реализовать методы QueryInterface, _AddRef и _Release или отнаследоваться от TInterfacedObject? Вне зависимости от того, отнаслеуюсь я своим классом от IUnknown или от INonCOMInterface? Если да, то я получу COM-Объект, потому что наличие этих методов, емнип, яляется необходимым и достаточным условием для сохдания COM-объекта
H>>Ответ да. Ты получишь COM-объект. Но интерфейс INonCOMObject так и не будет COM-интерфейсом, ведь дергая методы _AddRef, _Release, QueryInterface ты работаешь только с IUnknown.
M>Еще раз:
M>
M>Должен ли я в MyClass реализовывать QueryInterface, _AddRef и _Release. Если нет, то почему?
Должен, ибо это декларирует IUnknown от которого ты наследовал свой интерфейс. Тут есть еще очень важный момент. Если ты продекларируешь в классе реализуцию только одного интерфейса (MyInterface), от таких объектов нельзя будет получить IUnknown. Для получения IUnknown нужно декларировать реализацию обоих интерфейсов (или иметь предком класс реализующий IUnknown).
Здравствуйте, kuj, Вы писали:
H>>Ответ да. Ты получишь COM-объект. Но интерфейс INonCOMObject так и не будет COM-интерфейсом, ведь дергая методы _AddRef, _Release, QueryInterface ты работаешь только с IUnknown.
kuj>Нет, ты работаешь с INonCOMObject, а не с IUnknown. INonCOMObject наследует эти методы от IUnknown.
Зависит от реализации. Если я наследуюсь от класса реализующего IUnknown, то и работать, дергая эти методы, буду c IUnknown. Если реализую сам и не продекларирую реализацию IUnknown, работать буду с INonCOMObject.
Здравствуйте, hattab, Вы писали:
M>>Должен ли я в MyClass реализовывать QueryInterface, _AddRef и _Release. Если нет, то почему?
H>Должен, ибо это декларирует IUnknown от которого ты наследовал свой интерфейс. Тут есть еще очень важный момент. Если ты продекларируешь в классе реализуцию только одного интерфейса (MyInterface), от таких объектов нельзя будет получить IUnknown. Для получения IUnknown нужно декларировать реализацию обоих интерфейсов (или иметь предком класс реализующий IUnknown).
....из чего следует, что вызов INonCOMObject._AddRef есть вызов метода INonCOMObject интерфейса, а не IUnknown интерфейса... Понял наконец?
Здравствуйте, gandjustas, Вы писали:
H>>Здравствуйте, Mamut, Вы писали: M>>>То есть я все равно обязан реализовать методы QueryInterface, _AddRef и _Release или отнаследоваться от TInterfacedObject? Вне зависимости от того, отнаслеуюсь я своим классом от IUnknown или от INonCOMInterface? Если да, то я получу COM-Объект, потому что наличие этих методов, емнип, яляется необходимым и достаточным условием для сохдания COM-объекта
H>>Ответ да. Ты получишь COM-объект. Но интерфейс INonCOMObject так и не будет COM-интерфейсом, ведь дергая методы _AddRef, _Release, QueryInterface ты работаешь только с IUnknown. G>Изучай ООП. Наследование моделирует отношение "является", то есть если INonCOMObject наследует IUnknown, то он в каком-то смысле является IUnknown. IUnknown в свою очередь является COM интерфейсом, следовательно INonCOMObject является COM интерфейсом. G>Или для тебя ООП тоже не авторитет?
INonCOMObject расширяет IUnknown. Говоря о INonCONObject мы говорим не только о трех методах. INonCOMObject не может являться COM-интерфейсом если имеет декларации несовместимые с требованиями COM. Это так сложно понять?
Здравствуйте, gandjustas, Вы писали:
H>>>>Не нужно повторяться в вопросах, я на это уже отвечал: помимо IUnknown, это совместимые типы и соглашения о вызовах (но с соглашениями не все однозначно, как с типами). G>>>Ссылку на источник сего откровения. H>>Да какую ссылку тебе нужно? Роджерсона (Inside COM) можешь почитать. Только если ты сам выводы делать не будешь, то не найдешь в книге выводов. G>Ты действительно думаешь что твои выводы правильнее того что сказал человек, который COM придумал?
Здравствуйте, kuj, Вы писали:
M>>>Должен ли я в MyClass реализовывать QueryInterface, _AddRef и _Release. Если нет, то почему?
H>>Должен, ибо это декларирует IUnknown от которого ты наследовал свой интерфейс. Тут есть еще очень важный момент. Если ты продекларируешь в классе реализуцию только одного интерфейса (MyInterface), от таких объектов нельзя будет получить IUnknown. Для получения IUnknown нужно декларировать реализацию обоих интерфейсов (или иметь предком класс реализующий IUnknown).
kuj>....из чего следует, что вызов INonCOMObject._AddRef есть вызов метода INonCOMObject интерфейса, а не IUnknown интерфейса... Понял наконец?
Вообще то, от реализации зависит... Но даже если рассмотреть твой вариант, какая разница, чей это вызов в вопросе COM не COM?
kuj>>....из чего следует, что вызов INonCOMObject._AddRef есть вызов метода INonCOMObject интерфейса, а не IUnknown интерфейса... Понял наконец?
H>Вообще то, от реализации зависит... Но даже если рассмотреть твой вариант, какая разница, чей это вызов в вопросе COM не COM?
Объект, реализующий AddRef, Release и QueryInterface является чем?
M>>>>ну это да. В дельфи интерфейсами банальные абстрактные классы обозваны
H>>>Вообще-то в Delphi интерфейсы, это интерфейсы, а абстрактные классы, это абстрактные классы (терминология C++ не катит). Абстрактные классы обозначаются по другому: H>>>
H>>>TAbstarctClass = Class Abstract (TObject)
H>>> ...
H>>>End;
H>>>
M>>Чем интерфейс в Дельфи отличается от абстрактного класса?
H>Интерфейс -- чистая декларация. Абстрактный класс -- класс, объекты которого нельзя создать (хотя в 2006 есть глюк, и такие объекты создать можно). При этом, абстрактный класс, может иметь любые поля/свойства/методы (не обязательно абстрактые).
В общем, разницы никакой за двумя важными исключениями:
1. Interface позволяет множественное наследование
2. В классах, наследуемых от Interface СOM-совместимые методы гвоздями прибиваются в самое начало vtable для обеспечения COM-совместимости. Таким образом, любой класс, наследуемый (в цепочке любой длины) от IUnknown будет COM-объектом, потому что у него будет как минимум три COM-совместимых метода: AddRef, Rekease и QueryInterface
Все эти извращения нужны только для одного — облегчить создание COM-объектов в Delphi
M>>Должен ли я в MyClass реализовывать QueryInterface, _AddRef и _Release. Если нет, то почему?
H>Должен, ибо это декларирует IUnknown от которого ты наследовал свой интерфейс. Тут есть еще очень важный момент. Если ты продекларируешь в классе реализуцию только одного интерфейса (MyInterface), от таких объектов нельзя будет получить IUnknown. Для получения IUnknown нужно декларировать реализацию обоих интерфейсов (или иметь предком класс реализующий IUnknown).
Mr.Cat пишет: > Здравствуйте, OCTAGRAM, Вы писали: > OCT>А из метода можно выйти так, чтобы его кадр остался? Чтобы потом > вернуться? > > В несколько ограниченном виде — да, с помощью yield. Замыкания (в > принципе — из той же оперы — сохранение контекста вызова) в C# тоже имеются. http://www.thinkingms.com/pensieve/CommentView,guid,fd10bfa8-1aeb-4353-84c8-cd80e418424f.aspx
In the CLR, when a method returns its stack frame is torn down. So
there is no way that the local variables can actually preserve state.
The solution taken by the C# team is turn the method that implements the
yield statement into a class.
Судя по тому, что эта конструкция прозрачно вписана в язык, есть
надежда, что CLR поменяют, и это не будет хаком.
> А теперь объясните, при чем здесь стек.
При том, что http://en.wikipedia.org/wiki/Funarg_problem
Конкретно Upwards funarg problem.
Therefore, the activation record containing the called function's
state variables must not be deallocated when the function returns,
violating the stack-based function call paradigm.
> А то, что технически такая модель может быть реализована с помощью > стека — это ни о чем не говорит. Если Вы против такой концепции — мне > придется Вас расстроить
Я не против концепции, я против конкретной реализации.
Здравствуйте, OCTAGRAM, Вы писали:
>> А то, что технически такая модель может быть реализована с помощью >> стека — это ни о чем не говорит. Если Вы против такой концепции — мне >> придется Вас расстроить OCT>Я не против концепции, я против конкретной реализации.
Здравствуйте, iyura, Вы писали:
I>Здравствуйте, _d_m_, Вы писали:
I>>>Ну как сказать... а если вместо := да заставят писать assign
___>>Если бы у бабушки был х.. она была бы дедушкой.
I>Типа пошутил?
Нет. Пословица такая русская есть, здесь насчет "а если вместо..."
I>>>Вспомни фортрановские LE, GE и как то там LT, кажется.... Как по мне , то гораздо проще <=, >=, <
___>>Это ты к чему вообще?
I>К тому, что синтаксис должен быть, по возможности, немногословным. И одним из недостатков Delphi (сугубо с моей точки зрения) как раз и есть все эти "приколы" типа :=, begin/end, procedure....
Ну хорошо, теперь понятно. А то какие-то там фортрановские бла-бла-бла, которые еще я почему-то должен помнить . Я их не знал вовсе. Но если уж вопрос встал о многословности, то GE и >= имеют одинаковое кол-во символов, не находишь?
Здравствуйте, hattab, Вы писали:
H>>>Проблема в практике использования таких конфигов. Заметь, я уже неоднократно писал, что можно и все правильно сделать.
___>>А причем здесь Дельфи или ДотНет?
H>Рекомендуемый/пропогандируемый/самый популярный/(подставь сам) подход может быть не идеальным. Если следуя ему легко сотворить корягу -- она таки будет сотворена (вспомним нападки на Delphi за то, что малограмотные кодеры размещали всю логику в обработчиках формы. Казалось бы, причем тут Delphi?). Еще пояснения нужны?
Не помню таких нападок. Т.е. ты считаешь, что использование конфигов есть потенциальный путь сотворить корягу, и что это недостаток ДотНет?
Здравствуйте, iyura, Вы писали:
I>Правда никого не заботило то, что при старте приложения при одном открытом окошке с маленькис списком 70Мб памяти было откушено. Мда...сумбурно получается. Короче, программист воспитаный на неуправляемой среде пишет качественнее
Не надо путать память и workset. Воспользуйся поиском хотя бы по местному форуму дотнет. Вопрос этот уже набил аскомину.
Здравствуйте, iyura, Вы писали:
MC>>Предполагается, что Dispose технически корректно освобождает ресурсы.
I>Вот как-то не складывается у меня с этим. Не спорю, скорее по незнанию\отсутствию опыта. Но я бы хотел сазать, что, например в С++ такие вещи идеологически чище. Чего стоят деструкторы в шарпе — читаешь документацию и сразу выпить хочется
Выпить хочется — это по другой причине. А деструкторов в шарпе — нет. Есть финализаторы — а это огромная разница. Читать Рихтера.
