Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>MyInterface расширяется декларацией IUnknown. Расширение ни есть наследование. Идеология. G>>Эта идеология расходится с ООП. При том, что COM сам по себе никак с ООП не конфликтует. G>>Это еще раз доказывает что делфи — плохой язык.
H>Ни с чем она не расходится и не конфликтует. Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП.
Здравствуйте, hattab, Вы писали:
H>>>RTTI как раз таки позволяет (и много чего еще позволяет)
kuj>>Что в таком случае мешает неявно добавить всех предков в таблицу COM (или что там в Delphi в этой роли)?
H>Мешает неявность. Язык требует явного указания реализуемых интерфейсов. Кстати, этот вопрос (иерархию) вполне можно разруливать в момент компиляции и без всякой RTTI.
Вот я и говорю, что язык кривой, раз требует явно перечислять всех предков интерфейса... Это ж надо было додуматься
Здравствуйте, hattab, Вы писали:
H>>>MyInterface расширяется декларацией IUnknown. Расширение ни есть наследование. Идеология. G>>Эта идеология расходится с ООП. При том, что COM сам по себе никак с ООП не конфликтует. G>>Это еще раз доказывает что делфи — плохой язык.
H>Ни с чем она не расходится и не конфликтует. Интерфейсы, вообще, не являются фундаментальной единицей идеологии ООП.
Слышал про одну из основных/фундаментальных техник ОО, называемой инкапсуляцией? Похоже, что нет...
Здравствуйте, _d_m_, Вы писали:
kuj>>Или ты пытаешься сказать своим "слово Рихтер", что деструктор в управляемой среде и деструктор в native различаются? Ну так ясное дело различаются. Тем, что в управляемой среде момент вызова деструктора и порядок вызова деструкторов связных объектов недетерминированные.
___>Ну наконец-то ты понял.
Что именно я понял? Что ты сморозил глупость "деструкторов в шарпе нет", а теперь пытаешься выкрутиться? Ну да... вроде понял.
kuj>>>Что в таком случае мешает неявно добавить всех предков в таблицу COM (или что там в Delphi в этой роли)?
H>>Мешает неявность. Язык требует явного указания реализуемых интерфейсов. Кстати, этот вопрос (иерархию) вполне можно разруливать в момент компиляции и без всякой RTTI.
kuj>Вот я и говорю, что язык кривой, раз требует явно перечислять всех предков интерфейса... Это ж надо было додуматься
В обоих классах мы обязаны реализовать методы _AddRef, _Release и QueryInterface, потому что так требует их наличие в IUnknown, но MyClass мы не сможем привести к IUnknown. Несмотря на то, что он является наследником IUnknown
Здравствуйте, hattab, Вы писали:
H>Передай, пожалуйста, по DCOM, динамический массив из анси-строк. Если при этом у тебя проблем с маршалингом не возникнет, я съем свои носки, а ты сможешь сказать, что в Delphi все интерфейсы COM-совместимы.
Думаю, с custom маршалером можно будет передать без проблем.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, _d_m_, Вы писали:
kuj>>>Или ты пытаешься сказать своим "слово Рихтер", что деструктор в управляемой среде и деструктор в native различаются? Ну так ясное дело различаются. Тем, что в управляемой среде момент вызова деструктора и порядок вызова деструкторов связных объектов недетерминированные.
___>>Ну наконец-то ты понял.
kuj>Что именно я понял? Что ты сморозил глупость "деструкторов в шарпе нет", а теперь пытаешься выкрутиться? Ну да... вроде понял.
Глупости морозишь здесь пока ты. Только глупцы упорствуют в своем невежестве.
Джеффри Рихтер, "CLR via C# программирование на платформе Microsoft .Net Framework 2.0 на языке C#", Microsoft Press, Русская редакция, Питер 2007, стр. 457:
Внимание! Разработчики, хорошо знакомые с С++, заметят, что специальный синтаксис, используемый в C# для определения метода Finalize, похож на синтаксис деструктора С++. Действительно, в предыдущих версиях спецификации С# этот метод назывался деструктором (destructor). Однако метод Finalize работает совсем не так, как неуправляемый деструктор С++, что приводит в замешательство многих разработчиков, переходящих с одного языка на другой.
Беда в том, что ... бла-бла-бла ...
Во второй версии спецификации C# метод с таким синтаксисом официально назван завершителем (finalizer). Группа разработчиков C# также рассматривала возможность изменения синтаксиса этого метода, чтобы отказаться от применения тильды (~), но это сделало бы непригодным синтаксис имеющихся программ. Поэтому изменилось лишь название, а синтаксис оставлен прежним.
The C# Language Specification is the authoritative source for C# grammar and syntax. It contains detailed information about all aspects of the language and many points not covered in the Visual C# product documentation. The C# 3.0 specification has been updated and merged with earlier versions into a single document.
То есть спецификация составлена из старых документов.
Теперь открываем Ecma-334 (C# Language Specification), написаный для второго шарпа
17.12 Finalizers
[Note: In the previous version of this standard, what is now referred to as a "finalizer" was called a
"destructor". Experience has shown that the term "destructor" caused confusion and often resulted to
incorrect expectations, especially to programmers knowing C++. In C++, a destructor is called in a
determinate manner, whereas, in C#, a finalizer is not. To get determinate behavior from C#, one should use
Dispose. end note]
1.6.7.6 Destructors
A destructor is a member that implements the actions required to destruct an instance of a class. Destructors cannot have parameters, they cannot have accessibility modifiers, and they cannot be invoked explicitly. The destructor for an instance is invoked automatically during garbage collection.
The garbage collector is allowed wide latitude in deciding when to collect objects and run destructors. Specifically, the timing of destructor invocations is not deterministic, and destructors may be executed on any thread. For these and other reasons, classes should implement destructors only when no other solutions are feasible.
The using statement provides a better approach to object destruction.
Здравствуйте, kuj, Вы писали:
kuj>Вообщем сам кури, умник.
Не курю, глупник. Тебе уже сто раз сказано и на пальцах показано, что тебе еще не понятно? Что, кроме документации по Visual Studio (ака MSDN) ты больше ничего не знаешь и знать не хочешь?
Здравствуйте, _d_m_, Вы писали:
___>Не курю, глупник. Тебе уже сто раз сказано и на пальцах показано, что тебе еще не понятно? Что, кроме документации по Visual Studio (ака MSDN) ты больше ничего не знаешь и знать не хочешь?
Есть конкретный документ — спецификация языка C# 3.0, в котором четко написано что такое деструкторы в C#. Если до тебя так туго доходит, то извини — ничем больше помочь не могу.
Здравствуйте, _d_m_, Вы писали:
___>Ну хорошо, теперь понятно. А то какие-то там фортрановские бла-бла-бла, которые еще я почему-то должен помнить . Я их не знал вовсе. Но если уж вопрос встал о многословности, то GE и >= имеют одинаковое кол-во символов, не находишь?
Ну про фортрановское бла-бла ты расскажи людям, которые вычислительной математикой занимаются Я,например, работал в проекте в котором половина всего был фортран (финансы, оценка рисков)
Вот не помню точно, но в фортране >= это Greate Or Equal, т.е. GOE (три знака точно, но могу и ошибаться)
Но речь-то не о фортране (дедушка живее всех живых )
Здравствуйте, kuj, Вы писали:
kuj>Еще и как имеет. Java и .NET позволяют бОльшую часть кода покрыть юнит-тестами, и позволяют применять более высокоуровневые техники: IoC, AOP, O/RM ect
Юнит тестами и С++ покрывается. IoC, AOP — не знаю, что это. ORM и С++ живет. И в чем уникальность .Net и Java?
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, iyura, Вы писали:
kuj>За не совсем правильный стиль у нас бьют. Больно. Если не помогает, то выгоняют в связи с профнепригодностью.
kuj>Да не об аккуратности речь. Речь о человеческом факторе — свойстве допускать ошибки. Все ошибаются. А когда сроки поджимают, то может появится желание "срезать углы".
Вот и я о том же. И NET тут не сильно поможет
I>>А вот как себя поведет
I>>
I>>try
I>>{
I>> using(obj )
I>> {
I>> если тут облом с obj
I>> }
I>>}
I>>catch(...........)
I>>{
I>> тут хочу рассказать об обломе с obj
I>>}
I>>
kuj>В смысле как? using не делает catch. Соответственно "твой" catch поймает эксепшн.
Не буду спорить, но сдается мне, что using эквивалентно блоку try{} finally{} и если это так, то не вполне понятно как эксепшн пробьется в мой кэтч
kuj>>>Забыл упомянуть, что для доступа к БД фактически повсеместно используются O/RM, которые сами заботятся о подключениях. Единственное, где надо помнить о using — для TransactionScope`ов.
I>>Весьма спорно.
kuj>Что именно спорно? Что надо TransactionScope оборачивать в using или явно вызывать Dispose, т.к. это IDisposable объект?
Здравствуйте, _d_m_, Вы писали:
___>Не надо путать память и workset. Воспользуйся поиском хотя бы по местному форуму дотнет. Вопрос этот уже набил аскомину.
Мнэ.....А в двух словах? Ну искать и вправду долго.
Здравствуйте, iyura, Вы писали:
kuj>>Еще и как имеет. Java и .NET позволяют бОльшую часть кода покрыть юнит-тестами, и позволяют применять более высокоуровневые техники: IoC, AOP, O/RM ect
I>Юнит тестами и С++ покрывается.
Пример interaction testing на C++ в студию.
I>IoC, AOP — не знаю, что это. ORM и С++ живет.
Пример O/RM для C++ (native) в студию.
I>И в чем уникальность .Net и Java?
Странный вопрос, учитывая, что ты банально их не знаешь.
Здравствуйте, iyura, Вы писали:
kuj>>За не совсем правильный стиль у нас бьют. Больно. Если не помогает, то выгоняют в связи с профнепригодностью.
kuj>>Да не об аккуратности речь. Речь о человеческом факторе — свойстве допускать ошибки. Все ошибаются. А когда сроки поджимают, то может появится желание "срезать углы".
I>Вот и я о том же. И NET тут не сильно поможет
Вообще-то поможет и сильно.
I>>>А вот как себя поведет
I>>>
I>>>try
I>>>{
I>>> using(obj )
I>>> {
I>>> если тут облом с obj
I>>> }
I>>>}
I>>>catch(...........)
I>>>{
I>>> тут хочу рассказать об обломе с obj
I>>>}
I>>>
kuj>>В смысле как? using не делает catch. Соответственно "твой" catch поймает эксепшн.
I>Не буду спорить, но сдается мне, что using эквивалентно блоку try{} finally{} и если это так, то не вполне понятно как эксепшн пробьется в мой кэтч
Ликбез: эксепшины обрабатываются блоком catch, а finally только гарантирует, что код в этом блоке будет выполнен даже, если вылетел эксепшн.
kuj>>>>Забыл упомянуть, что для доступа к БД фактически повсеместно используются O/RM, которые сами заботятся о подключениях. Единственное, где надо помнить о using — для TransactionScope`ов.
I>>>Весьма спорно.
kuj>>Что именно спорно? Что надо TransactionScope оборачивать в using или явно вызывать Dispose, т.к. это IDisposable объект?
I>Спорно повсеместное использование O/RM
В .NET/Java/Ruby (Ruby on Rails) ect O/RM используются повсеместно за очень редкими исключениями.