Продолжать работать на Delphi смысла нет. Для этого существует множество причин:
Borland перестала "рожать" свои идеи и фактически переродилась в производителя редакторов под MS продукты. Наглядный пример - C# Builder, Delphi.NET, которые уже не имеют своих компиляторов и библиотек. Плюс официальные заявления представителей Borland, о том, что движение на Линукс платформе ноль, а на MS платформе полным ходом и выступления представителей MS, что они пожалуй разрешат Borland поиметь денюшек с .NET платформы.
Думаю никому напоминать не надо, что уже давно Borland отказалась от исследовательской работы и все ее новые продукты - фактически переделанные IDE и добавленные новые компоненты, многие из которых еще и сторонних производителей. Последняя их потуга была Киликс, которая удачно провалилась, так как Линукс все таки не дорос в полном обьеме до десктопной платформы, да и если бы дорос, то ниша то уже все равно занята - это Java, Python, C++ с навороченными библиотеками Qt и wxWindows.
Думаю с этим вопросом все понятно. Теперь хотелось бы сказать по поводу сравнения той же Delphi.NET и VS.NET. Лично мое мнение, что легче выучить C#, чем программировать под .NET с Borland-овской IDE. Это мнение сложилось из следующих факторов:
1. У Borland есть JBuilder - IDE, смахивающая на Delphi, но только для Java. Что в ней особенно впечатлило: постоянное отставание от спецификаций языка Java, дикие тормоза и глюки самой IDE и нарушение стандартов Java (это и измененный механизм работы редакторов свойств в IDE и собственные компоненты доступа к данным, аля Delphi DataSet, которые с одной стороны нам привычны и удобны, а с другой стороны абсолютно не совместимы с технологиями доступа к данным Java и соотвествующе с этими компонентами могут работать только DataAware компоненты Borland, хотя в Java через интерфейс IDocument может работать с данными абсолютно любой визуальный компонент).
2. У Borland теперь есть C# Builder, о котором люди рассказывают, что он тоже страшно тормозит и глючит, причем ловит баги в тех же местах, что и VS.NET. Такое чувство, что ребята из Borland сильно не заморачивались, а просто IDE "слепили, из того что было", т.е. уже готовеньких классов .NET и запустили в продажу, как отдельный продукт
Теперь представим себе, что Borland очень серьезно подошла к проблеме и действительно сделала Delphi.NET очень качественным продуктом. Однако каким бы он удобным и привычным он не был, все равно стоит помнить, что он полностью построен на платформе .NET, а это значит, что:
1. VS.NET является кроссязыковой IDE, т.е. в нее можно встроить поддержку полноценного проектирования программ на любом языке, реализованного под нее, вплоть до собственного (например есть даже плагин для IDE VS.NET, позволяющей в ней разрабатывать программы для Питона). В Delphi.NET как я понимаю этого полноценно не будет, так что придется ставить рядышком и VS.NET, когда Вам захочется дописать к примеру библиотеки, написанные на Фортране
2. Delphi.NET всегда будет здорово отставать от развития C# - например уже вышла бета версия C# 2.0, в котором он стал поддерживать макеты (generics), стал ко всему прочему функциональным языком, вплоть до поддержки генераторов, была полноценно реализована поддержка итераторов, сделана возможность организации анонимных методов для описания событий и т.д. Нововведения скажем так впечатляющие и революционные, у меня сложилось впечатление, что сейчас по скорости своего развития C# догнал один из самых быстро развивающихся языков - Питон. Сможет ли Borland успеть со своим Object Pascal.NET за C# ? Думаю нет, так как фактически у самой MS VB.NET отстает от C# и имеет ряд ограничений.

Теперь насчет доступа к данным. У Borland это всегда было сильной стороной, компоненты доступа к данным были удобны, элегантны и эффективны. Скорее всего в Delphi.NET Borland перенесет свою модель доступа к данным DBExpress, как это было проделано в JBuilder. С одной стороны это удобно разработчикам Delphi, с другой стороны я бы хотел заметить, что не смотря на сложность восприятия ADO.NET на самом деле очень удачное и эффективное решение. Сама модель работы с данных была содрана с DataWindow Power Builder-а (т.е. набор данных - это фактически не привязанный к источнику многомерный массив), такая модель до сих пор считается самой лучшей из существующих. Во вторых MS ввело расширения, позволяющие эффективно проводить на клиентском приложении операции с данными - фактически DataSet ADO.NET - это аналог схемы БД, в которую Вы можете положить таблицы, запросы и процедуры, нарисовать между ними связи, определить ограничения и уникальность полей и даже организовать каскадные обновления и удаления. С учетом того, что в ADO.NET все реализовано по схеме отложенных изменений (кэшированных изменений), все это дает прекрасную возможность проведения предварительных проверок и манипуляций с набором данных до записи изменений в СУБД, что очень не маловажно для клиентских приложений, работающих с удаленной БД. Так же для сортировки и фильтрации данных используется специальный компонент DataView, который накладывается на набор данных в качестве призмы.

P.S. Я честно говоря на .NET до сих пор ничего еще не пишу (основные инструменты - Delphi и Java) по той простой причине, что хотел убедиться в его оправданности и надежности, посмотреть, как много сторонних компонентов под него появится, будет ли MS его дальше развивать или остановиться на достигнутом, станет ли он де-факто языком программирования на Windows платформах. Как только вышла спецификация C# 2.0, все вопросы отпали сами собой - язык действительно становиться де-факто и с этим спорить уже трудно. Так что я считаю, что 2004 год, самое время начинать переползать на C#.

авторвывод:
целесообразней изучать c++
Странный вывод, можно подумать ООП модель C++ имеет что то общее с Java, C# или Delphi. Насколько я понимаю, у него она поддерживается только на уровне препроцессора, а у этих языков все на таблицах виртуальных вызовов повязано, соотвествующе и методики программирования разные получаются - кто то на шаблонах рисует, кто то на интерфейсах изгаляется. А уж про базовые библиотеки, без которых никуда, я вообще молчу - тут даже Java и C# в разные стороны расползлись, а у C++ так вообще разных библиотек целая тонна: MFC, Qt, wxWindows, Gt и никакого общего стандарта.

Хотя приятно, что в C# вводят шаблоны - честно говоря доставало каждый раз несчастные коллекции наследовать, чтобы просто сделать их типизированными :)

Минуточку :) Я и не отрицаю свое не знание C++. Тут 2 варианта - или я чего то не понял или народ, который у меня под боком на нем работает ни черта оказывается не знает. Отбросим в сторону COM и я уточню вопрос:
В самом языке C++ можно по ходу программы, а не компиляции, получить неизвестный обьект, изучить его метаструктуру, привести его к какому то интерфейсу/классу (естественно, если обьект согласен) и попользоваться им в свое удовольствие ? Примитивный пример из C#, Java, Delphi: в рунтайме берем контейнер с напиханными обьектами Object, бежим по нему и для всех контролсов, отзывающихся как Button вызываем событие Click. Второй вопрос: можно ли в рунтайме создать экземпляр обьекта по неизвестному заранее классу, когда на входе мы описываем метакласс некоего базового типа и с помощью него создаем обьекты, которые на самом деле являются экземплярами обьектов не этого примитивного класса, а того, который был нам передан на самом деле ? Третий вопрос: могу ли я исследовать неизвестный мне обьект, получить значения его свойств и вызвать его методы, без его приведения к какому то известному мне интерфейсу/типу ? И последний вопрос - есть ли в C++ поддержка делегатов, которые позволяют типизированно описать указатель на функцию и оперировать дальше им, как обычной ссылкой ?
Если Вы на каждый вопрос ответите ДА, то обещаю, что завтра же синсталю VS C++.NET и начну разбираться, почему я так долго его игнорировал. Даю честное пионерское слово :)

P.S. Небольшое несогласие с моей стороны: истинно ООП - это не когда множественное наследование поддерживается, а когда все в языке обьекты, в том числе сами классы и примитивные типы. В этом плане истинно ООП получаются Smalltalk и Python. Может кто еще есть, просто не знаю.

Я как раз четко понимаю, как это реализовано в Delphi, Java и C#. Все мои вопросы - это свойства языка и к оберткам они никакого отношения не имеют. Простой пример - Delphi когда компилирует класс, то для protected, public свойств и методов генерит таблицу RTTI (run-time type information), причем их из за наследования даже не одна получается. С нее я в runtime по прямому доступу памяти могу получить информацию абсолютно по любому обьекту. В C# и Java все сделано более культурней и для доступа к RTTI есть технология REFLECTION, через которую можно элементарным образом обследовать любые обьекты. Причем это свойство языка, а не какой то обертки. Даже в Python есть поддержка своеобразного REFLECTION, где через системные словари пространства можно изучать любые зарегестрированные в системе модули, классы, обьекты, переменные и т.д.

Ваш же приведенный пример - это чистой воды OLE и к языку C++ он никакого отношения не имеет. И кстати не правильно говорить, что если Java к примеру написана на C, то значит уже изначально C имеет те же возможности, что и Java. Это тоже самое, что сказать, что C был написан на ассемблере и поэтому ассемблер обладает в семантике программирования теми же свойствами, что и C :) На C пишутся компиляторы и среды исполнения, а вот механизмы языков, которые на них крутятся могут вообще быть непохожими на C.

Пример Ваш не принимаю, так как Вы не поняли меня. Приведу пример создания экземпляра переданной ссылки на класс на Delphi:


Заметьте в приведенном примере не используются никакие обертки и функция вообще ничего не знает о том, обьект какого класса необходимо создать. Все это реализуется на уровне языка и компилятора. Единственное, что в данном случае указанно для компилятора, это что класс должен обязательно быть контролом, чтобы не было возможности вызвать функцию например на невизуальный компонент. Если с примера убрать имена классов TCONTROL и TBUTTON, то все остальное - это чистый Object Pascal и он будет работать не только в Delphi, но и на любом другом компиляторе Object Pascal (тот же Free Pascal для Linux).

Так что прошу привести аналогичный моему пример на чистом C++, без использования COM или еще чего нибудь - все только на ключевых словах C++ :)

P.S. Кстати, хочу уточнить, что это не спор и не попытка доказать, что C++ хуже, а кто то лучше. Я просто пытаюсь выяснить для себя точно, насколько C++ отличается по модели работы ООП от других, известных мне языков. Люблю я сравнивать диалекты и модели разных языков, каюсь, моя слабость :)

Ну так вот с чего все и началось - что я в самом первом сообщении своего топика написал, что у C++ это все реализуется в template (а это обработка на уровне компилятора), а у Delphi, C# и Java через RTTI (а это обработка в runtime) и модель ООП у них разная :) Что Вы только что и подтвердили.

Я просто слова пропускал иногда. Правильно читать мое утверждение:
"Модель реализации технологии ООП в этих языках разная". Т.е. они все ООП, но у C++ есть кое что, чего нет у других языков, но так же кое чего отсутствует.

Вы кстати себе малость противоречите:
автор
да в C++ не всё обьекты, да в C++ нет reflection.

а далее:
автор
Действительно странно еще из института помню про vtables и rtti в C++.

По идее если нет reflection, то нет и RTTI. Разве не так ? Если RTTI есть, значит пусть через Reflection, пусть прямо по адресу памяти, но программа доступ к ней получить может и VTables спокойненько прочесть. Я кстати и не говорю, что отсутствие RTTI плохо - наоборот иногда хорошо, не надо лопатить VTables при вызове каждого виртуального метода и смотреть, кого там надо вызывать. В этом плане для меня всегда templates нравились тем, что на них можно красиво и без всяких заморочек с наследованием лепить прототипы классов (шаблоны), а reflection нравилось тем, что позволяло делать универсальные классы и компоненты, для обработки других классов и компонентов. Раз в C# это обьединят, значит получиться то, что мне нужно.

P.S. И кстати я не пониимаю, почему многие называют C# и Java игрушкой. Эти платформы (заметьте именно платформы, а не языки) сразу интегрированны с современными технологиями, имеют четкие стандарты для решения множества задач и содержат в себе продуманную и полную иерархию классов в фундаментальных библиотеках.