Здравствуйте, DarkGray, Вы писали:

DG>Проблема в том, что хоть в BCB по сравнению с Delphi есть плюсы (язык C++), так есть и большие минусы:
DG>плохая поддержка стандарта C++,
Кстати, не такая уж и плохая. Она где-то на уровне между VC++ 6 и VC++ 7.

A>>На счет C# на первом месте — считаю что спорно, но спорить не буду.
DG>Но C# бесспорно лучше Delphi, вот C# и Delphi.Net будут равны,
Весьма сомнительно. Особенно в свете C# 2.
DG>или даже Delphi.Net будет лучше (за счет своих классов),
А что там особенного с ее классами и что помешает использовать "ее" классы в проектах на C#?

A>>И надо еще Java куда-нибудь воткнуть, куда-нибудь наверх, у них тоже очень хороший набор библиотек.
DG>ИМХО, на Java-е мало пишут под винды....
Много. Я бы сказал очень много. Но в основном это enterprise-level решения и outsourcing.

Здравствуйте, AMogil, Вы писали:

А>>В действительности о Delphi, как таковой, можно забыть как о страшном сне. Borland ее развивать не будет. В более-менее серьезных проектах использовать Delphi, в виду убогости Object Pascal и, собственно, VCL, не рационально. Да и зачем, если есть .NET?.

AM>Могу допустить убогость VCL, но вопрос в чес убогость Object Pascal?
Delphi language? А сравните, например, с .NET-языками, C++, Java, OCaml... Благо, спецификации их доступны в Интернет.

Здравствуйте, <Аноним>, Вы писали:

А>Языки созданы для того, чтобы на них писать — в первую очередь. Именно потому популярность у профессионалов приобрели клоны C-синтаксиса, а не Pascal, Basic или тому подобного.

Это рассуждения ламера. Спорить с ними бесполезно. Человек или понимает всю глупость такого подхода или так и умирает ламером. Чувствуется, что ты это понимаешь, так как пишешь из под анонима.

А>Сарказм не виден? Я к тому, что такие категоричные заявления непрофессиональны.

Сарказ? Больше глупость. Катигоричности же тут никакой нет. Это просто мнение.

А>В действительности можно, если сильно захотеть. Вопрос в профессиональном опыте, коего Вам, судя по всему, не хватает. Не обессудьте.

Почему-то о профессиональном опыте обычно начинают говорить именно такие те кому его нехватает. Сдается мне что это как раз тот случай.

VD>>Хотя конечно чем их меньше, тем лучше. Ну, да хорошо спроектированная программа на любом языка старается их не делать. Что же касается стабильности, то тут С++ на последнем месте, так как язык не карантируем типобезопастности в рантайме. Молейшая ошибка и память испорчена...
А>Да-да, вопрос профессионального уровня.

Гарантия 100%. Доказана 20 годами применения С++. И как раз только отсуствие этого самого опыта может подвигнуть рассуждать о нем.

Здравствуйте, Gregory_krovosos, Вы писали:

G_>Например, я до сих пор не нашел аналога map в стандартной поставке Delphi (может быть гуру подскажут?)

TBucketList хотя конечно я вряд ли сойду за гуру по Дельфям. Если мне не изменяет память появилась в 6-ке.

G_> и мне пришлось написать на C++ DLL-ку и свой модифицированный TStringList, где поиск ключа идет со скоростью O(log n), а не простым перебором (каковой можно наблюдать в исходных текстах Delphi ).

А почему нельзя было отсортировать лист и применять бинарный поиск. Хотя конечно назвать коллекции Дельфей полноценными я бы тоже не осмелился.

G_>Далее, серьезный недостаток Delphi Pascal — отсутствие стековых объектов, все объекты — в дин. памяти и соот-но создание объекта и
G_>его уничтожение приходится делать собственноручно. Т.е. C++:

Вообще-то в дельфи есть тип object и record.

G_>{
G_> SOME_STACK stack(some_parameter);
G_> stack.push(123);
G_> ...
G_>}
G_>// stack уже автоматически уничтожен и его деструктор вызван

Так это наличие автоматического вызова деструктора/финалайзера. В Шарпе этого тоже нет. Но есть IDisposeble и инструкция using.

G_>Шаблоны бы не помешали, но вообще говоря это не must have.

Как минимум более типобезопасно. Так что уж точно не повредит.

G_>Вообщем, надеюсь главная мысль ясна. Дельфи — замечательная "обертка" для проекта под Windows, он легко "тянет" и маленькие, и большие проекты. А еще лучше он становится, если его доработать своими собственными библиотеками (хоть на C++, хоть на чем еще . И под него удобно делать и ActiveX-ы и еще много чего другого.

Ну, Дельфи как бы кончился на версии 7. 8-ка уже дотнет-продкт. А дотнет обладает и всеми приемуществами Дельфией и предоставляет кучу других. Те же коллекции там реализованы намного лучше. А после появления дженериков в области коллекций вообще проблем не будет.

G_>PS Один из отцов-основателей Delphi ушел в Microsoft разрабатывать C#, так что нетрудно заметить как отличные идеи в Delphi (скажем as и is) переползли в C#.

Ну, с Явы он точно больше содрал. Из Дельфи больше взято в ВыньФормс. Но это библиотека, а не язык.

G_>PPS К сожалению, Delphi конец. Мы получим еше одно обновление Delphi 7.1, после чего будет развиваться только Delphi .NET.
G_>Король умер, да здравствует король.

А от чего же конец то? Дельфи 8 лучше 7-ки хотя бы тем что к ВЦЛ прибавилась огромная ФЦЛ дотнета. Язык стал надежнее. Решены проблемы с тем же Free.

Что так печально то?

Здравствуйте, Gregory_krovosos, Вы писали:

G_>1. создать нормальный мап — совершенно нетривиальная задача! (ну-ка давайте-ка по памяти напишем процедурку удаления узла из красно-черного или AVL дерева, слабо?)

"Нормальные" мапы не пишутся на деревьях. Да и зачем по памяти. В гугле за пять минут можно надыбать алгоритмы. Они очень не сложне. Другое дело что размножать вручную типизированные коллекции без генерации кода не очень разумно. Хотя для одного проекта приемлемо. Не так уж много коллекций обычно в проектах.

G_>2. стандартизация — великая вещь, а так у каждого будут в проекте свои контейнеры и свои способы работы с ними и т.д., это очень плохо

А кто мешает написать публичную библиотеку? Я вообще не очень понимаю почему для Дельфи библиотек с окошками и феничками хоть завались, а с коллекциями и алгоритмами на пальцах одной руки можно перечесть.

G_>То, что STL появилась на свет и успешно существует и очень многими используется доказывает мою правоту.

Ага. А так же ее доказывает. Наличие МФЦ, АТЛ-а, буста, и других библиотек содержащих свои коллекции.

Здравствуйте, Serginio1, Вы писали:

S>А под мап можно подогнать и Хэш таблицы и BitArray и B+ деревья и просто массив и у всех есть плюсы и минусы и своя область применения.

О! Блин, золотые слова! Вот бы ты их и в обратную сторону понимал. Вспомни свое Б+-дерево без итераторов.

Здравствуйте, kuj, Вы писали:

S>> Не ошибается тот кто ничего не делает, а кривизны в стандартных библиотеках хватает выше крыши как в Delphi, Net, Java.
kuj>Можно узнать перечень "кривизны" в .NET? И что подразумевается под "выше крыши", применительно к кривизне .NET?

Она есть везде. В дотнете есть и код с багами. И не оптимальные реализации (одна сериализация чего стоит). А узнать можно почитав с недельку соотвествующий форум на этом сайте.


S>> Нет кривизны только в STL !!!!!!
kuj>Ага... Особенно в std::auto_ptr.
kuj>Задумайтесь, почему многие предпочитают заменять "стандартный" STL в VС++ на STLPort, а вместо std::auto_ptr использовать boost::shared_ptr

Блин. Ну, что за народ?! Сарказма отличить не может.

Здравствуйте, Serginio1, Вы писали:

S> Не боись дженерики заменят шаблоны. А насчет Хэйлсбега ты зря. Можно спорить на что Net (Delph.Net,C#) похож на Java или Delphi но общего у них очень много.

А ты задумывался почему? Не потому ли что это все ОО компонентные системы RAD-разработки?

Здравствуйте, s.ts, Вы писали:

ST>ИМХО отказ от разделения декларации и реализации ухудшает возможности разбиения на модули гораздо больше чем в Delphi по сравнению с C++. На что у изобретателей Java есть стандартный ответ : "если правильно проектировать ...".

Хороший, кстати, ответ. Но разбиение на модули никак не связано с пре-декларациями. В том же C# 2.0 и VB.NET 2.0 будут введены средства разбиения на модули без предеклараций. Просто класс можно будет пометить как разбиваемый и положить отдельные его части в разные файлы.

Забавно что люди привыкшие к предекларациям всячески защищают этот атавизм. Правда отвыкнув и вирнувшись к нему обратно сильно матерятся и проклинают его.

Ну, да видимо это все от того, что каждый колик свое болото хвалит.

Здравствуйте, <Аноним>, Вы писали:

А>Нет у него уже никаких перспектив. Борланд полностью отказалась от VCL в пользу .NET Стоит признать, правильно сделала.

Борланд от ВЦЛ? А это ничего что он портировал ВЦЛ под дотнет?

А>>чем у Delphi. Чего спорить, "бацанье" интерфейса у Борланда лучше чем у VC (все версии).
А>Смотрим на WinForms и забываем про VCL, как про страшный сон.

Скорее забыаем о дельфи. А если уж ты используеш дельфи то можно и не забывать.

Правда выйдет Авалон с XAML-ом и про них обоих можно будет забыть. Но годков эдак через 5.

Здравствуйте, <Аноним>, Вы писали:

А>перегрузку операторов не умеет, функции с переменным количеством параметров не умеет.

Отстал ты от жизни.

А>В итоге ни тебе патернов более-менее сложных (хотя бы интеллектуальных указателей, без которых сейчас никуда),

Опять отстал. В дельфи 8 это все уже не нужно.

А> ни тебе универсальных структур, специализируемых через шаблон на этапе компиляции.

Ну, если не смотреть на скорость, то в есть ОО-решения. Они даже покомпактнее выходят.

А> Да чего только стоит возможность инстанцирования (!) абстрактного класса! Потому на Делфи дальше пользовательского интерфейса не уедешь.

Ну, это снение человека никогда на ней не писавшего. Все на ней можно сделать. Много конечто чего нет, но не критично это все. За то есть другие фичи. Поддержка компонентнго подхода, КОМ-а. А теперь и весь дотнет.

Здравствуйте, <Аноним>, Вы писали:

А>Функции с переменным числом параметров?...

Про этот багадром в плюсах лучше молчать. Как-то умнее выглядеть при этом начинаешь.

А вообще в 8-ке много чего появилось. Разве что шаблонов нет.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Serginio1, Вы писали:

S>> Не боись дженерики заменят шаблоны. А насчет Хэйлсбега ты зря. Можно спорить на что Net (Delph.Net,C#) похож на Java или Delphi но общего у них очень много.

VD>А ты задумывался почему? Не потому ли что это все ОО компонентные системы RAD-разработки?
Многие RAD сти не нужны, а нужна единая иерархия классов,RTTI, метаклассы итд.
В С++ другие задачи прежде всего скорость в угоду гибкости. От виртуальныех методов шарахаются как черт от ладана, поэтому шаблоны и преобладают в этом языке. Причем RTTI можно подключать или отключать по усмотрению итд. При стройной же иерархии легче строить сложные системы, а учитывая современные мощности компьютеров на скорость уже давно забили.
И какие радости в С# если ты используешь консоль???? И много ли используешь встроенную сериализацию???
Компонентнось в этих языках всего лишь одно из достоинств единой иерархии классов.

Здравствуйте, kuj, Вы писали:

DG>>Но C# бесспорно лучше Delphi, вот C# и Delphi.Net будут равны,
kuj>Весьма сомнительно. Особенно в свете C# 2.
DG>>или даже Delphi.Net будет лучше (за счет своих классов),
Поддержка Delphi.Net фремворк 2 будет полной.
http://www.rsdn.ru/forum/Message.aspx?mid=606662&amp;only=1

Автор: Arioch
Дата: 14.04.04

Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, AMogil, Вы писали:

А>>>В действительности о Delphi, как таковой, можно забыть как о страшном сне. Borland ее развивать не будет. В более-менее серьезных проектах использовать Delphi, в виду убогости Object Pascal и, собственно, VCL, не рационально. Да и зачем, если есть .NET?.

AM>>Могу допустить убогость VCL, но вопрос в чес убогость Object Pascal?
kuj>Delphi language? А сравните, например, с .NET-языками, C++, Java, OCaml... Благо, спецификации их доступны в Интернет.
Delphi.Net language?
А если серьезно все проблемы в поверхностном знании этого могучего языка. Помню было сравнение языков в "Программисте" при этом много ляпусов было допущено и Виртовские языки весьма неплохо смотрелись а победила там ADA.

Здравствуйте, Serginio1, Вы писали:

VD>>А ты задумывался почему? Не потому ли что это все ОО компонентные системы RAD-разработки?
S> Многие RAD сти не нужны, а нужна единая иерархия классов,RTTI, метаклассы итд.

Интересно к чему это ты сказал? И почему ты считаешь, что именно ты знаешь, что нужно, а что нет?

S> В С++ другие задачи прежде всего скорость в угоду гибкости.

Может прежде чем делать такие заявления хоть чуть-чуть изучить С++? А ведь смешно выглядит.

S> От виртуальныех методов шарахаются как черт от ладана, поэтому шаблоны и преобладают в этом языке.

Виртуальные методы в С++ ничем не хуже чем в Дельфи или еще где-то. И никто от них не шархается. Просто когда у тебя есть два пути решения одной и той же задачи, то (если ты конечно разумный человек) всегда выбереш самый просто, безопасный и быстрый спостоб. Вот шаблоны за частую и явлются таким выходом.

S> Причем RTTI можно подключать или отключать по усмотрению итд. При стройной же иерархии легче строить сложные системы, а учитывая современные мощности компьютеров на скорость уже давно забили.

И много ты сложных систем написал, что делаешь такие заявления?

S> И какие радости в С# если ты используешь консоль????

Все. Нет разницы коносльное приложение или куевое. Скорость разработки все равно выше.

S> И много ли используешь встроенную сериализацию???

А она то каким боком тут? Я ее вообще стараюсь не использовать.

S> Компонентнось в этих языках всего лишь одно из достоинств единой иерархии классов.

Полнейшая глупость. Компонентность вообще не зависит не от наличия иерархии не от классов. В КОМ небыло ни иерархии, ни классов в полном понимании этого слова, а компонентность была.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Serginio1, Вы писали:

VD>>>А ты задумывался почему? Не потому ли что это все ОО компонентные системы RAD-разработки?
S>> Многие RAD сти не нужны, а нужна единая иерархия классов,RTTI, метаклассы итд.

VD>Интересно к чему это ты сказал? И почему ты считаешь, что именно ты знаешь, что нужно, а что нет?
Delphi, Net, Ява единая иерархия классов от базового.

S>> В С++ другие задачи прежде всего скорость в угоду гибкости.

VD>Может прежде чем делать такие заявления хоть чуть-чуть изучить С++? А ведь смешно выглядит.
Ну да и почему же шаблоны являютс оотличительной частью С++???

S>> От виртуальныех методов шарахаются как черт от ладана, поэтому шаблоны и преобладают в этом языке.

VD>Виртуальные методы в С++ ничем не хуже чем в Дельфи или еще где-то. И никто от них не шархается. Просто когда у тебя есть два пути решения одной и той же задачи, то (если ты конечно разумный человек) всегда выбереш самый просто, безопасный и быстрый спостоб. Вот шаблоны за частую и явлются таким выходом.
Для мелких задач это нормально. Меня всегда удивляет почему это в С++ нет таких библиотек как Delphi, Net, Ява ?????
В чем проблема???? Или платформонезависимость мешает.
S>> Причем RTTI можно подключать или отключать по усмотрению итд. При стройной же иерархии легче строить сложные системы, а учитывая современные мощности компьютеров на скорость уже давно забили.

VD>И много ты сложных систем написал, что делаешь такие заявления?
А ты??? И почему это Net и Ява сделали ставку на стройную иерархию????

S>> И какие радости в С# если ты используешь консоль????

VD>Все. Нет разницы коносльное приложение или куевое. Скорость разработки все равно выше.
За счет чего??? Может за счет огромного количества классов и продуманной иерархии и имплементации интерфейсов????
Тогда в чем проблемы C++.
S>> И много ли используешь встроенную сериализацию???

VD>А она то каким боком тут? Я ее вообще стараюсь не использовать.
Компонентность подразымевает прежде всего Persistent, запоминание состояния. Которое возможно в том числе и через сериализацию и

S>> Компонентнось в этих языках всего лишь одно из достоинств единой иерархии классов.

VD>Полнейшая глупость. Компонентность вообще не зависит не от наличия иерархии не от классов. В КОМ небыло ни иерархии, ни классов в полном понимании этого слова, а компонентность была.
Которая базируется на на определенных интерфейсах может тебе их всех перечислить, и которые есть и в Net??????
А что такой интерфейс??? Не абстрактный ли виртуальный клас????? И наследование интерфейсов к иерархии не имеет никакого отношения????
А то что имплементируют их в классах тоже никакого отношения не имеет???? И получить тот или иной интерфейс через QueryInterface тоже никакого отношения к иерархии не имеет????
Причем в Delphi из любого контрола легко сделать Олеконтрол

Здравствуйте, Serginio1, Вы писали:

S> Delphi, Net, Ява единая иерархия классов от базового.

А MFC — нет?

S>>> В С++ другие задачи прежде всего скорость в угоду гибкости.

VD>>Может прежде чем делать такие заявления хоть чуть-чуть изучить С++? А ведь смешно выглядит.
S> Ну да и почему же шаблоны являютс оотличительной частью С++???

Ты уверен, что отвечаешь на заданный вопрос? И вообще, вопросом на вопрос не хорошо как то...

S> Для мелких задач это нормально. Меня всегда удивляет почему это в С++ нет таких библиотек как Delphi, Net, Ява ?????

А тебя не удивляют рассуждения человека вообще не знающего С++ о библиотеках в ней?

Сравнивать же библиотеки Дельфи с библиотеками С++ лучше не надо. По количеству библиотек плюса намного в пререди. Другое дело, что VCL намного проще в применении из-за ориентации на компонентные технологии и RAD. Ну, да они и в СппБилдере доступна.

S> В чем проблема???? Или платформонезависимость мешает.

Отсуствие знания предмета спора мешает.

VD>>И много ты сложных систем написал, что делаешь такие заявления?
S> А ты??? И почему это Net и Ява сделали ставку на стройную иерархию????

Четыре штуки . Причем на плюсах из них две. Правда конечно не все целиком, но руку прикладывал и проектировал.

S> За счет чего??? Может за счет огромного количества классов и продуманной иерархии и имплементации интерфейсов????

Скорее из-за интели-сенс, броузера классов, и т.п. Но и из-за простоты и удобства библиотек конечно же. Однако библиотеки тоже не относятся к ГУИ.

S> Тогда в чем проблемы C++.

В сложности языка. Например, при наличии моря библиотек все же не удается так быстро и просто задейсвовать нужный класс. Та же хэш-таблица требует много обвязочного кода (это только в Яве и дотнете хэш автоматом вычисляется).

S> Компонентность подразымевает прежде всего Persistent, запоминание состояния. Которое возможно в том числе и через сериализацию и

Так твоей persistents при разработке достигаетя сериализацией в код. Которая вооще не важно сколько времени отнимает, так как происходит в дизайнтайме. В рантайме же просто выполняется код. И его скорость оптимальна.

VD>>В КОМ небыло ни иерархии, ни классов в полном понимании этого слова, а компонентность была.
S> Которая базируется на на определенных интерфейсах может тебе их всех перечислить, и которые есть и в Net??????

Пожалуйста: IUncnown, IDispatch.

S> А что такой интерфейс??? Не абстрактный ли виртуальный клас?????

В КОМ и дотнете эти понятия очень похожи. А в общем случае это просто набор публичных методов.

S> И наследование интерфейсов к иерархии не имеет никакого отношения????

А им никто почти не пользуется. Весь кайф интерфейсов в том, что они позволяют создавать составные абстракции.

S> А то что имплементируют их в классах тоже никакого отношения не имеет????

К компонентности то? Конечно никакого. Это детали реализации.

S> И получить тот или иной интерфейс через QueryInterface тоже никакого отношения к иерархии не имеет????

Это детали самого КОМ-а.

S> Причем в Delphi из любого контрола легко сделать Олеконтрол

Здорово. Это видимо тоже доказывает, что "Компонентнось в этих языках всего лишь одно из достоинств единой иерархии классов."?

Здравствуйте, VladD2, Вы писали:



VD>В сложности языка. Например, при наличии моря библиотек все же не удается так быстро и просто задейсвовать нужный класс. Та же хэш-таблица требует много обвязочного кода (это только в Яве и дотнете хэш автоматом вычисляется).
За счет того, что эти операции были введены в базовый класс и его продуманная структура. Хотя в Delphi же все пляшет вокруг TObject,
как выделение памяти через виртуальный статический метод NewInstance и еще кучи методов происанных в VMT. И на этом базовом объекте очень легко строить любые иерархии. В том числе и уход от множественного наследования обусловлен сложностью поддержания таких структур.

S>> Компонентность подразымевает прежде всего Persistent, запоминание состояния. Которое возможно в том числе и через сериализацию и

VD>Так твоей persistents при разработке достигаетя сериализацией в код. Которая вооще не важно сколько времени отнимает, так как происходит в дизайнтайме. В рантайме же просто выполняется код. И его скорость оптимальна.
Я же написал в том,числе. А как например с большими двоичными данными его тоже в Base64 запихивать или лучше в ресурсы закинуть.
VD>>>В КОМ небыло ни иерархии, ни классов в полном понимании этого слова, а компонентность была.
S>> Которая базируется на на определенных интерфейсах может тебе их всех перечислить, и которые есть и в Net??????

VD>Пожалуйста: IUncnown, IDispatch.
IUnknown, IOleClientSite,
IOleControlSite, IOleInPlaceSite, IOleInPlaceFrame, IDispatch,
IPropertyNotifySink, ISimpleFrameSite,IAdviseSink, IAdviseSink2,
IDataObject итд


S>> А что такой интерфейс??? Не абстрактный ли виртуальный клас?????

VD>В КОМ и дотнете эти понятия очень похожи. А в общем случае это просто набор публичных методов.

S>> И наследование интерфейсов к иерархии не имеет никакого отношения????

VD>А им никто почти не пользуется. Весь кайф интерфейсов в том, что они позволяют создавать составные абстракции.
Ну да методы IUnknown нигде не используются. Опять же в основе любого интерфейса лежит базовый интерфейс.
К Net это не имеет отношения т.к. там другой механизм (и в чемто это даже и плохо, т.к. иногда нужно запросить некий интерфейс который имплементирует объект являющийся полем объекта).

S>> А то что имплементируют их в классах тоже никакого отношения не имеет????

В свое время можно было легко обмениваться виртуальными объектами между С++ и Delphi т.к. последовательность описания методов однообразно ложилась в VMT. В COM тоже самое.
VD>К компонентности то? Конечно никакого. Это детали реализации.
За то к набору поддерживаемых интерфейсов, получаемые через ...

S>> И получить тот или иной интерфейс через QueryInterface тоже никакого отношения к иерархии не имеет????

VD>Это детали самого КОМ-а.

S>> Причем в Delphi из любого контрола легко сделать Олеконтрол

VD>Здорово. Это видимо тоже доказывает, что "Компонентнось в этих языках всего лишь одно из достоинств единой иерархии классов."?
Конечно!!!!! Плюс в Delphi и Яве большую помощь оказывают метаклассы.
Сделай в Delphi перегрузку методов и шаблоны или кодогенерацию то ....

Здравствуйте, Serginio1, Вы писали:

S> За счет того, что эти операции были введены в базовый класс и его продуманная структура. Хотя в Delphi же все пляшет вокруг TObject,

Э батенька. Ни Дельфи, ни С++ не позволяют трактовать встроенные типы как классы. Тут уже нужен подход на уровне языка и среды исполнения.

VD>>Пожалуйста: IUncnown, IDispatch.

S>IOleClientSite,
S> IOleControlSite, IOleInPlaceSite, IOleInPlaceFrame, IDispatch,
S> IPropertyNotifySink, ISimpleFrameSite,IAdviseSink, IAdviseSink2,
S> IDataObject итд

Это не есть базовые интерфейсы. Эдак можно все созданные на дотнете интерфейсы к дотнету приписать.

К компонентной модели это точно не относится. Ты еще не забыл по какому поводу ты высказывался?

S> Ну да методы IUnknown нигде не используются. Опять же в основе любого интерфейса лежит базовый интерфейс.

Считай что IUnknown — это внутрення реализация ком-а на С++. В дотнете без нее спокойно обошлись. В Дельфи ее тоже почти не видно.

S> К Net это не имеет отношения т.к. там другой механизм (и в чемто это даже и плохо, т.к. иногда нужно запросить некий интерфейс который имплементирует объект являющийся полем объекта).

Реализуй механизм приведения типов...

S>>> А то что имплементируют их в классах тоже никакого отношения не имеет????

S> В свое время можно было легко обмениваться виртуальными объектами между С++ и Delphi т.к. последовательность описания методов однообразно ложилась в VMT. В COM тоже самое.

Это ты сам с собой споришь?

Что же касается VMT, то для КОМ-а была выбрана реализация С++ Дельфи ее просто стибрило для совместимости. Но VMT в С++ значительно сложнее из-за множественного наследования (МН). Именно из-за этого в КОМ-е было запрещено МН для интерфейсов.

S>>> Причем в Delphi из любого контрола легко сделать Олеконтрол

VD>>Здорово. Это видимо тоже доказывает, что "Компонентнось в этих языках всего лишь одно из достоинств единой иерархии классов."?
S> Конечно!!!!! Плюс в Delphi и Яве большую помощь оказывают метаклассы.

О, блин. Еще и какие-то метаклассы припер. Кстати, в Яве такой же рефлекшен как в дотнете. Так что к ней свои метаклассы лучше не прилетай.

S> Сделай в Delphi перегрузку методов и шаблоны или кодогенерацию то ....

Что, то?

В общем, фигню какую-то говоришь. Единая иерархия никакого отношения к поддержке комонентности н имеет.