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

S>>> Хотя C#,Delphi.Net и поддерживает перегрузку оператоторов но примняется очень редко, т.к. тянет за собой переопределение многих методов и не столь нужны как при создании шаблонов.
kuj>>Нет. Еще раз. Объясните зачем шаблонам перегрузка операторов?

S>В С++ существует такое понятие "функтор"
патерн
S>это объект который ведет себя как функция.
И где тут шаблоны?
S>

S>struct some
S>{
S>//...
S>};
S>struct some_dynamic_cmp
S>{
S>    bool operator()(const some& lhs, const some& rhs)
S>    {
S>    //Тут сравниваем
S>    }
S>};
S>void main()
S>{
S>    std::vector<some> some_vec;
S>    //Заполняем
S>    some_dynamic_cmp cmp;
S>    //Устанавлеваем правила сравнения
S>    std::sort(some_vec.begin(), some_vec.end(), cmp);
S>}
 


S>

kuj>>Нет. Это ведь совсем другое. Атрибуты — это декларативный способ описания поведения, а Вы предлагаете использовать императивный да еще и таким способом, что все плюсы данной методики становятся минусами. Понимаете?
S> Метаклассов нет в Net и этим они сильно обедненны.
А что такое "метаклассы" в Вашем понимании и в терминологии Делфи?
S>Частично атрибуты призваны залатывать дыры.
О каких, например, дырах идет речь?

S>>>>> Появилась перегрузка операторов. C++ с точки зрения архитектуры классов это вообще разные языки,
kuj>>>>А как языки можно сравнивать по некой "архитектуре классов"? Поясните.
S>>> Сами по себе языки достаточно одинаковы. Шаблоны тоже не являются языковой фичей.
kuj>>Являются, конечно. Посмотрите спецификацию С++.
S>>>Различие их только на уровне компиляторов.
kuj>>Сами себе противоречите...
S>>> А вот здесь как раз и проявляются различие в единой иерархии,
kuj>>Так "единая" иерархия это вообще-то фича библиотеки классов, но уж никак не языков. Я же Вам уже напоминал о MFC.
S> Еще раз. В MFC есть единая иерархия но ее нет во всех классах
Что подразумевается под "всеми классами"?
S>и по количеству не очень хороших откликов о ней можно попытаться найти в чем причина.
Вам доводилось на ней писать или Ваше предположение из категории "слышал звон да не знаю где он"? И разве мы обсуждаем достоинства/недостатки конкретных библиотек?
S>>>Объекты вообще близнецы братья.
kuj>>Не совсем. Вчасности, поведение деструкторов отличается. Да и, на сколько я знаю, для обычных классов (не COM) Delphi не предоставляет возможности множественного интерфейсного наследования.
S> Опятьже Есть класс TInterfacedObject в котором реализован IUnknown
IUnknown — это COM.
S>

S> TInterfacedObject = class(TObject, IInterface)
S>  protected
S>    FRefCount: Integer;
S>    function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
S>    function _AddRef: Integer; stdcall;
S>    function _Release: Integer; stdcall;
S>  public
S>    procedure AfterConstruction; override;
S>    procedure BeforeDestruction; override;
S>    class function NewInstance: TObject; override;
S>    property RefCount: Integer read FRefCount;
S>  end;

S>

S> Наследуясь от которого получаем реализацию IUnknown.
Это все конечно чудесно, но речь-то о другом...

S> А вот GetInterface(IID, Obj) уже реализован в базовом классе TObject. И InterfaceTable и смещения заполняются на этапе компиляции . Это к тому зачем нуже единый базовый класс и единый базовый метакласс. Если мне нужен объект с поддержкой интерфейсов или с подсчетом ссылок если мне лениво вызывать Free я использую TInterfacedObject иначе TObject Все от ситуации.
Это от лукавого — порождает overhead.
S>>>Причем в Delphi.Net через хэлперы была достигнута полная их совместимость.
kuj>>Что есть "хэлпер"?
S> Это фича компилятора. Если он не видит метода у объекта он обращается к хэлперу этого класса и если там есть такой метод то вызывает его.
S> http://www.rsdn.ru/Forum/Message.aspx?mid=548308&pg=1

Автор: Serginio1
Дата: 24.02.04

Больше похоже на костыль.
S>>>Так при едином базовом классе в этих средах работа выделение памяти, уничтожение, RTTI, работа с типом намного упрощает компиляцию и получение информации о типе в рантайме.
kuj>>Все это есть в MFC. Более того, есть полноценная бинарная сериализация объектов...
S>>> Тенденция развития говорит об этом. Подход С++ отвергнут в угоду гибгости.
kuj>>Наоборот — негибкости. Подумайте логически...
S> Я уже попытался ответить. В любом случае переубеждать не собираюсь.
Давайте определимся с терминологией.
1. "Гибкость" характеризуется количеством вариантов решения. Согласны?
2. В С++ мы не привязаны к конкретной библиотеке — хотим используем MFC и пишем для Windows, хотим используем Linux Qt и пишем под X Window. Хотим — вообще не используем классы. Пишем процедурными методами.
В .NET и Delphi мы автоматически привязываемся к System.Object и Object, соответственно.

Так где же гибкость выше?

S> Но вот по интефейсам дам еще одну ссылочку что бы было понятно зачем нужен единый базовый класс
S> http://www.rsdn.ru/Forum/Message.aspx?mid=527260&only=1

Автор: Serginio1
Дата: 02.02.04

Единый базовый класс может быть нужен, а может быть и не нужен. Все зависит от решаемых задач и, собственно, среды, в рамках которых, реализовывается задача.

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



kuj>>>Нет. Это ведь совсем другое. Атрибуты — это декларативный способ описания поведения, а Вы предлагаете использовать императивный да еще и таким способом, что все плюсы данной методики становятся минусами. Понимаете?
S>> Метаклассов нет в Net и этим они сильно обедненны.
kuj>А что такое "метаклассы" в Вашем понимании и в терминологии Делфи?
S>>Частично атрибуты призваны залатывать дыры.
kuj>О каких, например, дырах идет речь?

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


S>> Еще раз. В MFC есть единая иерархия но ее нет во всех классах
kuj>Что подразумевается под "всеми классами"?
А что можно еще полразумевать??? Единый базовый класс.
S>>и по количеству не очень хороших откликов о ней можно попытаться найти в чем причина.
kuj>Вам доводилось на ней писать или Ваше предположение из категории "слышал звон да не знаю где он"? И разве мы обсуждаем достоинства/недостатки конкретных библиотек?

S>>>>Объекты вообще близнецы братья.
kuj>>>Не совсем. Вчасности, поведение деструкторов отличается. Да и, на сколько я знаю, для обычных классов (не COM) Delphi не предоставляет возможности множественного интерфейсного наследования.
S>> Опятьже Есть класс TInterfacedObject в котором реализован IUnknown
kuj>IUnknown — это COM.
Да уж. COM намного больше чем определие IUnknown. Как видишь IInterface имеет такуюже сигнатуру но различные названия.
А TInterfacedObject это обычный класс.
S>>

S>> TInterfacedObject = class(TObject, IInterface)
S>>  protected
S>>    FRefCount: Integer;
S>>    function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
S>>    function _AddRef: Integer; stdcall;
S>>    function _Release: Integer; stdcall;
S>>  public
S>>    procedure AfterConstruction; override;
S>>    procedure BeforeDestruction; override;
S>>    class function NewInstance: TObject; override;
S>>    property RefCount: Integer read FRefCount;
S>>  end;

S>>

S>> Наследуясь от которого получаем реализацию IUnknown.
kuj>Это все конечно чудесно, но речь-то о другом...

S>> А вот GetInterface(IID, Obj) уже реализован в базовом классе TObject. И InterfaceTable и смещения заполняются на этапе компиляции . Это к тому зачем нуже единый базовый класс и единый базовый метакласс. Если мне нужен объект с поддержкой интерфейсов или с подсчетом ссылок если мне лениво вызывать Free я использую TInterfacedObject иначе TObject Все от ситуации.
kuj>Это от лукавого — порождает overhead.
И где он??? И где лукавство??? Это пример продуманной архитектуры классов. Экономия огромного количества времени на рутину.
S>>>>Причем в Delphi.Net через хэлперы была достигнута полная их совместимость.
kuj>>>Что есть "хэлпер"?
S>> Это фича компилятора. Если он не видит метода у объекта он обращается к хэлперу этого класса и если там есть такой метод то вызывает его.
S>> http://www.rsdn.ru/Forum/Message.aspx?mid=548308&pg=1

Автор: Serginio1
Дата: 24.02.04

kuj>Больше похоже на костыль.
Как скажешь. Только за счет костылей полностью совместимый код с Net. И в чем костыли??? Это фича компилятора очень удобно когда нужно расширить код не прибегая к наследованию в том числе и saled классов.
S>>>>Так при едином базовом классе в этих средах работа выделение памяти, уничтожение, RTTI, работа с типом намного упрощает компиляцию и получение информации о типе в рантайме.
kuj>>>Все это есть в MFC. Более того, есть полноценная бинарная сериализация объектов...
S>>>> Тенденция развития говорит об этом. Подход С++ отвергнут в угоду гибгости.
kuj>>>Наоборот — негибкости. Подумайте логически...
S>> Я уже попытался ответить. В любом случае переубеждать не собираюсь.
kuj>Давайте определимся с терминологией.
kuj>1. "Гибкость" характеризуется количеством вариантов решения. Согласны?
kuj>2. В С++ мы не привязаны к конкретной библиотеке — хотим используем MFC и пишем для Windows, хотим используем Linux Qt и пишем под X Window. Хотим — вообще не используем классы. Пишем процедурными методами.
kuj>В .NET и Delphi мы автоматически привязываемся к System.Object и Object, соответственно.
Гибкость в создании сложной иерархии классов прежде всего, RTTI и уменьшение количества кода. Kylix тоже используется CLX.
Кроме того а кто мешает использовать статические методы????
Единая иерархия только требует поля со ссылкой на VMT (в Net еще на блок синхронизации который еще используется и при Objet.GetHashCode), плюс выделение памяти не в стеке (хотя и там можно, но грабли при передачи ссылки можно получить). И тебя эти затраты так смущают.
А ручная гибкость уже никому не нужна в сложных системах.
kuj>Так где же гибкость выше?

S>> Но вот по интефейсам дам еще одну ссылочку что бы было понятно зачем нужен единый базовый класс
S>> http://www.rsdn.ru/Forum/Message.aspx?mid=527260&only=1

Автор: Serginio1
Дата: 02.02.04

kuj>Единый базовый класс может быть нужен, а может быть и не нужен. Все зависит от решаемых задач и, собственно, среды, в рамках которых, реализовывается задача.

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

kuj>>построение "цепочек" делегатов (C++, мультиметод),
VD>мультиметоды — это вообще-то немного другое. Это выбор метода на основании рантайм типа. Этого не в С++, не в Шарпе нет. Хотя эмулируется на базе патерна "визитор".
Chain of Responsibility

kuj>> атрибуты (C++, атрибутивный COM в ATL)...

VD>С++-то тут причем? В Билдере тоже много наворотов, но вот к С++ они отношение имеют очень отдаленное.
При том, что ATL в мире C++ куда как популярнее CBuilder`а. Речь о легкости осуществления перехода.

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

kuj>>>>Нет. Это ведь совсем другое. Атрибуты — это декларативный способ описания поведения, а Вы предлагаете использовать императивный да еще и таким способом, что все плюсы данной методики становятся минусами. Понимаете?
S>>> Метаклассов нет в Net и этим они сильно обедненны.
kuj>>А что такое "метаклассы" в Вашем понимании и в терминологии Делфи?
S>>>Частично атрибуты призваны залатывать дыры.
kuj>>О каких, например, дырах идет речь?
S> Еще раз в Net нет статических виртуальных методов,
А зачем нужны статические виртуальные методы?
S>частично они перекрываются атрибутами но очень дорогой ценой,
Каким же образом?
S>т.к. каждый раз нужно десериализовывать объект либо его кэшировать.
Зачем?
S>>> А вот GetInterface(IID, Obj) уже реализован в базовом классе TObject. И InterfaceTable и смещения заполняются на этапе компиляции . Это к тому зачем нуже единый базовый класс и единый базовый метакласс. Если мне нужен объект с поддержкой интерфейсов или с подсчетом ссылок если мне лениво вызывать Free я использую TInterfacedObject иначе TObject Все от ситуации.
kuj>>Это от лукавого — порождает overhead.
S> И где он??? И где лукавство??? Это пример продуманной архитектуры классов. Экономия огромного количества времени на рутину.
overhead в реализация IUnknown для не-COM классов. Подумайте сами — зачем в не co-классе реализация AddRef, Release и QueryInterface...
S>>>>>Причем в Delphi.Net через хэлперы была достигнута полная их совместимость.
kuj>>>>Что есть "хэлпер"?
S>>> Это фича компилятора. Если он не видит метода у объекта он обращается к хэлперу этого класса и если там есть такой метод то вызывает его.
S>>> http://www.rsdn.ru/Forum/Message.aspx?mid=548308&pg=1

Автор: Serginio1
Дата: 24.02.04

kuj>>Больше похоже на костыль.
S> Как скажешь. Только за счет костылей полностью совместимый код с Net. И в чем костыли??? Это фича компилятора очень удобно когда нужно расширить код не прибегая к наследованию в том числе и saled классов.
А что, код можно расширять только наследованием? Агрегацию уже отменили?.. Или для ER-логики придумали нечто более эффективное?
S>>>>>Так при едином базовом классе в этих средах работа выделение памяти, уничтожение, RTTI, работа с типом намного упрощает компиляцию и получение информации о типе в рантайме.
kuj>>>>Все это есть в MFC. Более того, есть полноценная бинарная сериализация объектов...
S>>>>> Тенденция развития говорит об этом. Подход С++ отвергнут в угоду гибгости.
kuj>>>>Наоборот — негибкости. Подумайте логически...
S>>> Я уже попытался ответить. В любом случае переубеждать не собираюсь.
kuj>>Давайте определимся с терминологией.
kuj>>1. "Гибкость" характеризуется количеством вариантов решения. Согласны?
kuj>>2. В С++ мы не привязаны к конкретной библиотеке — хотим используем MFC и пишем для Windows, хотим используем Linux Qt и пишем под X Window. Хотим — вообще не используем классы. Пишем процедурными методами.
kuj>>В .NET и Delphi мы автоматически привязываемся к System.Object и Object, соответственно.
S> Гибкость в создании сложной иерархии классов прежде всего,
Так с созданием иерархии классов в C++ нет особых проблем. Да и с гибкостью, кстати, тоже, потому что: а) множественное наследование,
б) шаблоны, в) пространства имен, г) перегрузка операторов.
S>RTTI и уменьшение количества кода.
RTTI, кстати, подразумевает увеличение количества кода там, где можно обойтись строгой типизацией, на основе шаблонной специализации.
S>Kylix тоже используется CLX.
Ах, CLX...
S> Кроме того а кто мешает использовать статические методы????
Религия.
S> Единая иерархия только требует поля со ссылкой на VMT (в Net еще на блок синхронизации который еще используется и при Objet.GetHashCode), плюс выделение памяти не в стеке (хотя и там можно, но грабли при передачи ссылки можно получить). И тебя эти затраты так смущают.
Смущают. Честно. Есть класс задач, где они излишни, то бишь порождают пресловутый overhead.
S> А ручная гибкость уже никому не нужна в сложных системах.
Весьма спорно.

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

VD>>К сожалению в С++ таких среств маловато, а грабель приводящих к ошибкам достаточно.
NF>Но, согласитесь, C++ предоставляет огромную гибкость. Он позволяет быстро реализовывать "странные" идеи.

Странные идеи лучше вообще не реализовывать. Что же касается быстро, то это не так. С++ как раз обычно тормозит процесс разработки. Рано или поздно складывается ситуация когда из-за объемов или сложности проект начинает рассыпаться под собственным весом.

Конечно многое зависить от класса программистов, но если квалифицированный программист получает в руки более удобное и безопасное средсво, то скорость разработки значительно увеличивается. Для не опытного же программистоа это вообще единствнно разумное решение.

NF>Кстати, о таких языках. Вы имеете в виду, думаю, Delphi.

Не. К сожалению дельфи мало чем отличается от С++ в аспекте безопасности.

NF> Я сам не так давно пользовался исключительно им. Но он(а может и мои знания по нему) перестал удовлетворять моим запросам. Всё, что в нём удобно, имхо, это дизайн форм... Это моё лично мнение. Но их обычно приходиться делать меньше, чем живого кода.

Это не в корне не верный взгляд на программирование. Попробуй ответить на вопрос почему Дельфи позволяет упростить разработку форм? И ты увидиль, что Дельфи — это компонентная среда, и именно это позволяет сделать стольк простой дизайнер форм. Применяя приимущества компонентной разработки ты можешь значитель упростить многие аспекты разработки.

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

NF>А про ошибки типов... Можете не верить, но обычно удаётся заметить их ещё на этапе написания кода. Правда, не всегда, но тем не менее.

Могу. И видимо по тому, что имею 10-и летний опыт разработки на С++, а так же опыт руководством С++-программистами.

NF>А может быть, о нестабильности программ, написанных программистом?

Программист само собой вносит ошибки. Его класс может снизить их количество или увеличить. Но избавиться от них он не в состоянии.

При этом банальная реализация в языке типобезопастности снижает риск ошибки.

Поменять природу человека очень сложно. Дать же ему более качественные средства разработки относительно просто. Так зечем же упускать реальный шанс поднять качество производимого им ПО?

NF>Он и даёт наибольший эффект, когда имеет наибольшую свободу.

Свобода о которой говришь ты — это лишь илюзия.

Выражать свои мысли можно и на других языках. И за частую это может быть намного изящьнее. Так что это разговоры в пользу бедных.

NF>Думаю, дело не в языке, а в объёме кода. Там его тоже выше крыши. И такой продукт на Delphi... Это что-то около научной фантастики. Думаю, с этим Вы согласны.

Уморил. Да все проблемы программирования в объеме кода. Написать без ошибок "Привет, мир!" можно на любом языке.

Сказки про то что подобный продукт нельзя написать на дельфи или чем-то еще вообще не достойны обсуждения.

Будующие продукты МС будут все больше и больше переписываться/перекомпилироваться на управлямых языках/компиляторах. И делаться это будет именно из-за того, что они могут обеспечить большую надежность и безопасность.

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

VD>>Гы-гы. На С++ достаточно врубить ключик /clr и получишь менеджед-приложение. Так что совместимость на 100%.
S> С MFC,STL и OWL



ЗЫ

Может не стоит обсуждать вопросы в которых не имешь полного понимания?

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

kuj>При том, что ATL в мире C++ куда как популярнее CBuilder`а. Речь о легкости осуществления перехода.

Видимо я не очень доходчиво выразился. ATL никакого отношения к С++ не имеет. Да и нет в нем никаких атрибутов. Атрибуты есть в КОМ и сепециальной надстройке VS.

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

S>В-четвертых, корпорация Microsoft предполагает дать пользователю полный спектр взаимосвязанных систем базового программного обеспечения таких, как операционная система MS Longhorn, набор бизнес-серверов MS Business Servers, офисная система MS Office System, система автоматизации программирования MS Visual Studio.NET с включенной в нее MBF и, наконец, масштабируемые корпоративные системы MBS Axapta и MBS Navision. Последние будут иметь общую кодовую часть, базирующуюся на MBF и написанную на новом языке C#, который вскоре придется изучать всем, кто собирается разрабатывать сколь-нибудь эффективные программные приложения для локальных корпоративных сетей или глобальной сети Интернет.

А там есть ссылка на микрософт? если нет, то это журналистская отсебятина.

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

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

S>>В-четвертых, корпорация Microsoft предполагает дать пользователю полный спектр взаимосвязанных систем базового программного обеспечения таких, как операционная система MS Longhorn, набор бизнес-серверов MS Business Servers, офисная система MS Office System, система автоматизации программирования MS Visual Studio.NET с включенной в нее MBF и, наконец, масштабируемые корпоративные системы MBS Axapta и MBS Navision. Последние будут иметь общую кодовую часть, базирующуюся на MBF и написанную на новом языке C#, который вскоре придется изучать всем, кто собирается разрабатывать сколь-нибудь эффективные программные приложения для локальных корпоративных сетей или глобальной сети Интернет.

L>А там есть ссылка на микрософт? если нет, то это журналистская отсебятина.

Про отсебятину не надо, видел подобную инфу в заслуживающих доверия журналах, да и на самом микрософте вроде информация такая проходила...

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

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

L>>А там есть ссылка на микрософт? если нет, то это журналистская отсебятина.

К>Про отсебятину не надо, видел подобную инфу в заслуживающих доверия журналах, да и на самом микрософте вроде информация такая проходила...

Линк дашь?

Просто я пытаюсь отслеживать информацию по Аксапте, и ничего о том, что ее будут портировать (именно портировать Аксапту, а не писать новую систему) на Нет, не слышал. Возможно я что-то упустил.

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

L>Здравствуйте, Курилка, Вы писали:

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

L>>>А там есть ссылка на микрософт? если нет, то это журналистская отсебятина.

К>>Про отсебятину не надо, видел подобную инфу в заслуживающих доверия журналах, да и на самом микрософте вроде информация такая проходила...

L>Линк дашь?
Если бы был — дал бы

L>Просто я пытаюсь отслеживать информацию по Аксапте, и ничего о том, что ее будут портировать (именно портировать Аксапту, а не писать новую систему) на Нет, не слышал. Возможно я что-то упустил.

Посмотри лучше на форумах по аксапте, там гораздо вероятнее найти что-либо более информативное, если найдёшь — интересно было бы услышать

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

L>>Линк дашь?
К>Если бы был — дал бы

Значит отсебятина.

L>>Просто я пытаюсь отслеживать информацию по Аксапте, и ничего о том, что ее будут портировать (именно портировать Аксапту, а не писать новую систему) на Нет, не слышал. Возможно я что-то упустил.

К>Посмотри лучше на форумах по аксапте, там гораздо вероятнее найти что-либо более информативное, если найдёшь — интересно было бы услышать

Смотрю регулярно.

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

VD>Странные идеи лучше вообще не реализовывать. Что же касается быстро, то это не так. С++ как раз обычно тормозит процесс разработки. Рано или поздно складывается ситуация когда из-за объемов или сложности проект начинает рассыпаться под собственным весом.
Странные идею нужно реализовывать. Мне кажется, что именно они изменяют окружающую действительность. Спорить со вторым утверждением не буду. Я не встречал процессов рассыпания такого рода проектов. Возможно, потому, что всё, в чём участвовал не имело такого большого объёма или сложности.

VD>Конечно многое зависить от класса программистов, но если квалифицированный программист получает в руки более удобное и безопасное средсво, то скорость разработки значительно увеличивается. Для не опытного же программистоа это вообще единствнно разумное решение.
Согласен. Но что вы считаете более удобным, чем C++ средством? Я могу привести только C#.

VD>В общем, Дельфи имеет некоторый набор приемуществ которые отсутсвтуют в классическом С++. С++ тоже имет набор приемуществ. Правда их не так уж и много. Я бы виделил только два — обобщенное программирование и более удобная работа с указателями. Остальное уже не так существенно.
Ну-у-у... Мелочи, а приятно. Да и преимущества C++, имхо, именно в не слишком жёстком контроле...

VD>Могу. И видимо по тому, что имею 10-и летний опыт разработки на С++, а так же опыт руководством С++-программистами.
Ух ты... Таким опытом похвастать не могу. 5 лет в программировании, из них 2 года на С++... Так что поверим...

VD>Свобода о которой говришь ты — это лишь илюзия.
А свобода — всегда иллюзия.

VD>Сказки про то что подобный продукт нельзя написать на дельфи или чем-то еще вообще не достойны обсуждения.
Приведите, пожалуйста, примеры подобных продуктов, написанных на Delphi.

VD>Будующие продукты МС будут все больше и больше переписываться/перекомпилироваться на управлямых языках/компиляторах. И делаться это будет именно из-за того, что они могут обеспечить большую надежность и безопасность.
Мдя... Очень может быть. Оно и естественно. Прогресс не стоит на месте.

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

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

VD>>>Гы-гы. На С++ достаточно врубить ключик /clr и получишь менеджед-приложение. Так что совместимость на 100%.
S>> С MFC,STL и OWL

VD>

VD>ЗЫ

VD>Может не стоит обсуждать вопросы в которых не имешь полного понимания?
Читать внимательно надо. Я подтвердил. Но как быть с унсейвом. Ведь C++ практически весь на указателях. Или там повсеместно GC.Alloc и интероп????

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

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

kuj>>>>>Нет. Это ведь совсем другое. Атрибуты — это декларативный способ описания поведения, а Вы предлагаете использовать императивный да еще и таким способом, что все плюсы данной методики становятся минусами. Понимаете?
S>>>> Метаклассов нет в Net и этим они сильно обедненны.
kuj>>>А что такое "метаклассы" в Вашем понимании и в терминологии Делфи?
S>>>>Частично атрибуты призваны залатывать дыры.
kuj>>>О каких, например, дырах идет речь?
S>> Еще раз в Net нет статических виртуальных методов,
kuj>А зачем нужны статические виртуальные методы?
На них вся Delphi построена и компонентная модель (информация о типе, виртуальные конструкторы при создании объектов из метаклассов, пользовательская информация о типе ее расширение, в том числе и десериализация итд).
S>>частично они перекрываются атрибутами но очень дорогой ценой,
kuj>Каким же образом?
Attribute.GetCustomAttribute.
S>>т.к. каждый раз нужно десериализовывать объект либо его кэшировать.
kuj>Зачем?
Потому что разберись на досуге с Attribute.GetCustomAttribute.
S>>>> А вот GetInterface(IID, Obj) уже реализован в базовом классе TObject. И InterfaceTable и смещения заполняются на этапе компиляции . Это к тому зачем нуже единый базовый класс и единый базовый метакласс. Если мне нужен объект с поддержкой интерфейсов или с подсчетом ссылок если мне лениво вызывать Free я использую TInterfacedObject иначе TObject Все от ситуации.
kuj>>>Это от лукавого — порождает overhead.
S>> И где он??? И где лукавство??? Это пример продуманной архитектуры классов. Экономия огромного количества времени на рутину.
kuj>overhead в реализация IUnknown для не-COM классов. Подумайте сами — зачем в не co-классе реализация AddRef, Release и QueryInterface...
Есть строки, динамические массивы поддерживающие подсчет ссылок (AddRef, Release) но они не ком классы. Вместо QueryInterface в Delphi поддерживается конструкция as. То есть программирование с интерфейсами по технике такое же как и в Net. А совместимость с ком то куда же деваться. Если смотреть на Net то там AddRef, Release и не нужен из-за сборщика мусора, а вот с QueryInterface есть небольшая проблема,
если в Delphi есть директива Implements позволяющая реализовать некий интерфейс объектом являющимся полем объекта, то в Net ту должен в объекте реализовывать его полностью. Кроме того ссылки на методы интерфейса хранятся в VMT, а вот доступ к ним через InterfaceTable которая представляет массив с адресами (смещениями в VMT объекта) и доступ к ней осуществляется по индексу через ID интерфеса присвоенного ему в рантайме. А так как объетов может быть много то и памяти жрут достаточно много.
S>>>>>>Причем в Delphi.Net через хэлперы была достигнута полная их совместимость.
kuj>>>>>Что есть "хэлпер"?
S>>>> Это фича компилятора. Если он не видит метода у объекта он обращается к хэлперу этого класса и если там есть такой метод то вызывает его.
S>>>> http://www.rsdn.ru/Forum/Message.aspx?mid=548308&pg=1

Автор: Serginio1
Дата: 24.02.04

kuj>>>Больше похоже на костыль.
S>> Как скажешь. Только за счет костылей полностью совместимый код с Net. И в чем костыли??? Это фича компилятора очень удобно когда нужно расширить код не прибегая к наследованию в том числе и saled классов.
kuj>А что, код можно расширять только наследованием? Агрегацию уже отменили?.. Или для ER-логики придумали нечто более эффективное?
И перекрывать все методы ????? Ради добавления 2-3. Кроме того твой любимый оверхэд ни к чему хорошему не ведет.
S>>>>>>Так при едином базовом классе в этих средах работа выделение памяти, уничтожение, RTTI, работа с типом намного упрощает компиляцию и получение информации о типе в рантайме.
kuj>>>>>Все это есть в MFC. Более того, есть полноценная бинарная сериализация объектов...
S>>>>>> Тенденция развития говорит об этом. Подход С++ отвергнут в угоду гибгости.
kuj>>>>>Наоборот — негибкости. Подумайте логически...
S>>>> Я уже попытался ответить. В любом случае переубеждать не собираюсь.
kuj>>>Давайте определимся с терминологией.
kuj>>>1. "Гибкость" характеризуется количеством вариантов решения. Согласны?
kuj>>>2. В С++ мы не привязаны к конкретной библиотеке — хотим используем MFC и пишем для Windows, хотим используем Linux Qt и пишем под X Window. Хотим — вообще не используем классы. Пишем процедурными методами.
kuj>>>В .NET и Delphi мы автоматически привязываемся к System.Object и Object, соответственно.
S>> Гибкость в создании сложной иерархии классов прежде всего,
kuj>Так с созданием иерархии классов в C++ нет особых проблем. Да и с гибкостью, кстати, тоже, потому что: а) множественное наследование,
kuj>б) шаблоны, в) пространства имен, г) перегрузка операторов.
Гибкость нужна прежде всего компилятору и ООП. Все что ты привел имеет слабое отношение к ООП и RTTI
S>>RTTI и уменьшение количества кода.
kuj>RTTI, кстати, подразумевает увеличение количества кода там, где можно обойтись строгой типизацией, на основе шаблонной специализации.
S>>Kylix тоже используется CLX.
kuj>Ах, CLX...
S>> Кроме того а кто мешает использовать статические методы????
kuj>Религия.
Не религия а фундамент на котром стоит Delphi. И не только
http://www.rsdn.ru/forum/Message.aspx?mid=567965&only=1

Автор: Кодт
Дата: 15.03.04

http://www.rsdn.ru/forum/Message.aspx?mid=565396&only=1

Автор: _vovin
Дата: 11.03.04

S>> Единая иерархия только требует поля со ссылкой на VMT (в Net еще на блок синхронизации который еще используется и при Objet.GetHashCode), плюс выделение памяти не в стеке (хотя и там можно, но грабли при передачи ссылки можно получить). И тебя эти затраты так смущают.
kuj>Смущают. Честно. Есть класс задач, где они излишни, то бишь порождают пресловутый overhead.
S>> А ручная гибкость уже никому не нужна в сложных системах.
kuj>Весьма спорно.
Хорошо у меня есть много классов работающих в 4 раза быстрее нетовских (написанных на Net), есть объектная надстройка над файлами 1С типизированный аналог "объектов" 1С скорость в 30 раз и выше в зависимости от сложности. Думаешь кому нибудь это нужно?????
К сожалению простота и стандартность для большинства залог здоровья. А скорость нужна для очень узкого круга задач.

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

L>Здравствуйте, Курилка, Вы писали:

L>>>Линк дашь?
К>>Если бы был — дал бы

L>Значит отсебятина.

Вот это тоже отсебятина:
http://www.microsoft-watch.com/article2/0,4248,1274625,00.asp ?
(хотя там ключ. роль отдана Great Plains)

Вот ещё ссылочка интересная — http://www.businessframework.com/
(хотя сайт и не микрософтовский...)

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

К>Вот это тоже отсебятина:
К>http://www.microsoft-watch.com/article2/0,4248,1274625,00.asp ?
К>(хотя там ключ. роль отдана Great Plains)

Спасибо. На выходных обязательно посмотрю. Сейчас к сожалению на это ни времени ни возможности нет.

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

kuj>>При том, что ATL в мире C++ куда как популярнее CBuilder`а. Речь о легкости осуществления перехода.

VD>Видимо я не очень доходчиво выразился. ATL никакого отношения к С++ не имеет. Да и нет в нем никаких атрибутов. Атрибуты есть в КОМ и сепециальной надстройке VS.
В догонку почитайте еще это: ms-help://MS.MSDNQTR.2003APR.1033/dnmag01/html/attributes.htm

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

NF>Странные идею нужно реализовывать. Мне кажется, что именно они изменяют окружающую действительность.

Это романтика. На практике качественный софт — это продуманные и тщательно спроектированные решения. А это не совестимо со странностями. Другое дело, что идеи могут быть дерзкими и неординартыми. Но не странными!

NF> Спорить со вторым утверждением не буду. Я не встречал процессов рассыпания такого рода проектов. Возможно, потому, что всё, в чём участвовал не имело такого большого объёма или сложности.

А я видел. Сроки затягиваются так, что проект теряет свою актуальность.

NF>Согласен. Но что вы считаете более удобным, чем C++ средством? Я могу привести только C#.

Собствнно этого уже достаточно. Шарп во многом луше С++, хотя и далек от идеало. Есть правда еще ресерч-языки, но им всем не хватает того или иного.

Думаю, что C# 2.0 в сочетании с нашим R#-ом будет как раз шагом к некому идеалу.

NF>Ну-у-у... Мелочи, а приятно. Да и преимущества C++, имхо, именно в не слишком жёстком контроле...

Нет. Это недостаток. К приемуществам можно отнести поддержку различных парадигм программирования.

VD>>Свобода о которой говришь ты — это лишь илюзия.
NF>А свобода — всегда иллюзия.

Тут не поспоришь.

NF>Приведите, пожалуйста, примеры подобных продуктов, написанных на Delphi.

Море финансового софта. Есть игры, редакторы и многое другое. За конкретными ссылками лучше обращаться на сайты ее фанатов.

NF>Мдя... Очень может быть. Оно и естественно. Прогресс не стоит на месте.

К сожалению, многеи программисты так сильно держится за старые, что вообще не признают все новое прогрессом. Тут в параллельной ветке С++-ники очень часто говорят, что тот же дотнет — это регрес.