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

kuj>Но их суть (reference type, value type) отличается от их тезок в Delphi Language не менее сильно.
S>> в отличие от единого базового класса и иерархии классов очень схожих как в Delphi и Яве.
kuj>А что с базовым классом? Вы полагаете, что в C++ нет библиотек с единым (не таким уж и единым в случае Delphi, кстати) базовым классом? Про MFC, например, Вы ничего не слышали?
Разница в том, что если в Delphi я не наследуюсь ни от какого класса, это означает неявное наследование от TObject и все прелести с ним связанные, тогда как в С++ класс, не унаследованный ни от какого другого мало чем от структуры отличается.

Про MFC слышали, но лучше бы не слышали

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

AVK>>>>Ну то есть на самом деле Дельфи весьма серьезно от дотнета и джавы отличается? Ну так чего ж тогда споришь?
S>>> То есть компонентность
AVK>>Компонентность конечно не входит, этой идее сто лет в обед.
S> Тоько за счет компонентности у Delphi,Net и превликательна для большинства.
.NET привлекательна для большинства за счет компонентности у Delphi? Это как?

S>>> и сравнительно одинаковая архитектура классов
AVK>>Архитектура классов это не язык. А то что WinForms на VCL похожи, так это с самого начала сказано было.
Не сильно-то и похожи.

S>>> А is, as итд осталось тем же.
А что еще?

S>>> Кстати языковые различия
S>>> Features C# has that Delphi doesn't
S>>>===================================
S>>>11) try..catch..finally
Вудзрш совсем doesn't it?
S>>>14) You don't need to distribute Borland.Delphi.dll


S>>>Features Delphi has that C# doesn't
S>>>===================================
S>>>1) sub-range types
S>>>2) enums and sets are first-class types
А это как?
S>>>6) nested procedures
Зачем?
S>>>9) resourcestring s
А это что такое?
S>>>11) variants
Зачем? Есть ведь полноценная метаинформация.
S>>>13) sets with more than 64 elements
Интересно зачем? В каких задачах может понадобиться?
S>>>14) message handlers
Так ведь есть... Или тут подразумевается какая-то особенная языковая конструкция?
S>>>16) untyped parameters
А это как?

AVK>>И? Как видишь отличий дофига и больше.
S> 17 отличий это много у C# и 14 у Delphi ??? И у кого еще больше премуществ????
Преимуществ, судя по всему, больше все-таки у C#.

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

K_O>Разница в том, что если в Delphi я не наследуюсь ни от какого класса, это означает неявное наследование от TObject и все прелести с ним связанные, тогда как в С++ класс, не унаследованный ни от какого другого мало чем от структуры отличается.

В MFC вы тоже не напишете MFC-класс если не отнаследуете от CObject (Отличия тут только в явности и неявности этого наследования). К С++ MFC имеет отношение, только как к языку реализации, а не к общим принципам MFC.

K_O>Про MFC слышали, но лучше бы не слышали

А вот зарабатывать на ней многим удавалось ... особенно часто замечаю, что половина приложений устанавливаемых на моём десктопе за собой тянет mfc40.dll

C Уважением, Andir!

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

[offtop, немного развлечёмся Не для флейма!]

S>>>> А is, as итд осталось тем же.
kuj>А что еще?

Ну как же перевожу: "А есть, как и т.д. осталось тем же.", то есть налицо абсолютно верная фраза, правда никому не нужная :D

S>>>> Кстати языковые различия
S>>>> Features C# has that Delphi doesn't
S>>>>===================================
S>>>>11) try..catch..finally
kuj>Вудзрш совсем doesn't it?
S>>>>14) You don't need to distribute Borland.Delphi.dll
kuj>

Придёт время и Delphi возьмёт своё и огромный плюс возьмёт своё и с C# приложением придёться распространять Borland.Delphi.dll, хотя даже нет, она будет входить в состав операционной системы, мистер Хейлсберг из лагеря волков об этом позаботиться

S>>>>Features Delphi has that C# doesn't
S>>>>===================================
S>>>>1) sub-range types
S>>>>2) enums and sets are first-class types
kuj>А это как?

Первокласные дельфёвские типы что-ли не узнал?

S>>>>6) nested procedures
kuj>Зачем?

Наследие языка паскаль, анонимные методы очевидно более чем удобны. Однако их нет ведь ни там, ни там
Жаль только что нет
nested constants
nested properties
nested events
nested namespaces — ой а это есть ...

S>>>>9) resourcestring s
kuj>А это что такое?

Ну как же ты можешь не знать, что для того чтобы вытащить строку из ресурсов надо написать специальный класс в C# а вот в дельфи он вот он готовенький (сразу вспоминается любимый дельфистами вопрос: "А где найти компонент для [вставить сюда любое описание]!", правда есть и С++ аналогия: "Помогите ламеру!, Ламерский вопрос! и подобные ламерские заморочки ").

S>>>>11) variants
kuj>Зачем? Есть ведь полноценная метаинформация.

Э нет батенька, а как же общаться с COM-объектами ... Даёшь вариАнты для выбора, хочу так буду общаться, а захочу смогу и через Дельфи

S>>>>13) sets with more than 64 elements
kuj>Интересно зачем? В каких задачах может понадобиться?

Вы ещё не видели множества с более чем 64 элементами, тогда вам нужна перегрузка операторов и мы уже едем к вам.

S>>>>14) message handlers
kuj>Так ведь есть... Или тут подразумевается какая-то особенная языковая конструкция?

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

S>>>>16) untyped parameters
kuj>А это как?

Параметры без типов, Типы без параметров ... Лингво вообще такого слова не знает, только знает "untyped language" — язык без контроля типов ...

AVK>>>И? Как видишь отличий дофига и больше.
S>> 17 отличий это много у C# и 14 у Delphi ??? И у кого еще больше премуществ????
kuj>Преимуществ, судя по всему, больше все-таки у C#.

Ну что ты а как же замечательный язык Delphi, который явно превосходит все C-подобные языки из-за своей мощной архитектуры, созданной лет 8 назад ...
А серъёзно, перечислять различия языков — это какой-то нонсенс, то что слова begin — нету в C# не значит, что он не умеет "начинать". Есть языки, коренным образом отличающиеся от C# и ничего, прекрасно адаптируются к платформе .Net и сохраняют все свои основные достоинства, что говорит о довольно продвинутой архитектуре самой платформы.

P.S. Delphi.Net — адаптировалась к .Net намного дольше чем многие языки ... я бы назвал это устареванием положенных в основу концепций

P.S.2 Нисколько не претендую на серъёзность

C Уважением, Andir!

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

S>>> в отличие от единого базового класса и иерархии классов очень схожих как в Delphi и Яве.
kuj>>А что с базовым классом? Вы полагаете, что в C++ нет библиотек с единым (не таким уж и единым в случае Delphi, кстати) базовым классом? Про MFC, например, Вы ничего не слышали?
K_O>Разница в том, что если в Delphi я не наследуюсь ни от какого класса, это означает неявное наследование от TObject и все прелести с ним
K_O> связанные, тогда как в С++ класс, не унаследованный ни от какого другого мало чем от структуры отличается.
Так это ведь наоборот дает определенную гибкость. Не согласны?
K_O>Про MFC слышали, но лучше бы не слышали
Тем не менее он был и на нем писали. При чем писали обычно лучше, чем на Delphi (ну да, вопрос профессионального уровня)...

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

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

S> Да и M$ скоро Акзапту с Навижн под Net выпустят.

Откуда такая информация?

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

A>Жаль только что нет
A>nested constants

Это есть.

G_>>Для кого-то это все ерунда (у него допустим Windows 2003 стоит, где уже есть .NET framework),
G_>>а кого-то из клиентов это оттолкнет. А для компании важны все клиенты, сами понимаете
kuj>В действительности, если уж клиент может позволить себе преобрести ваше ПО, то и скачать 25-30MB для него труда не составит, потому как это копейки.

Это вопрос "порога вхождения", который включает в том числе и время.

G_>>>>1) VCL — достаточно продуманная и гибкая обертка для Windows GUI, которая берет на себя огромную часть рутины и позволяет программировать на высоком уровне абстракций (Button1.Caption := 'Ляля' и т.д.)
А>>>То же самое в WinForms. Как, впрочем, и в VBx(x<7) в связке с ActiveX-компонентами.
G_>>Ну нет. Я согласен, что WinForms как и C# и .NET — хорошая вещь (а как ей не быть таковой, если Microsoft опять .... как бы это выразиться ...
G_>>ну скажем позаимствовала все самые лучше идеи для разработки
kuj>А что Вы в этом видите предосудительного? Разве чьи-то авторские права были нарушены?

Это не в тему, вообще-то. Но зачем кричать про революционные идеи в .NET, если a) _НИЧЕГО_НОВОГО_ в .NET нету. _Н И Ч Е Г О_.
b) в .NET нет ни одной идеи, которая была _придумана в MS_.
Понимаете? Маркетинговый шум вокруг .NET совершенно не соотвествует содержанию .NET

G_>>Но VB с ActiveX — не предлагать!!!
G_>>Это мертворожденная технология (как VB так и ActiveX) и серьезные вещи на них делать не стоит.
kuj>Тем не менее, на них куда больше действительно серьезных коммерческих проектов. Пример Microstrategy. Разве есть что-то близкое по классу, но написанное на VCL? Я лично не знаю. Так что Вы весьма заблуждаетеся. Delphi (CBuilder) на западе распространены значительно в меньшей степени, чем VB, C++ или Java. Только на просторах постсоветских стран Delphi и CBuilder на столько популярны, что даже в институтах по ним читают целые курсы лекций...

Мы не имеем полной картины о том, где чего используют. Давайте говорить о том, что мы знаем. А мы знаем, что на Delphi
можно сделать все то же, что и на VB + ActiveX. Но! Можно сделать еще кучу всего дополнительного, понимаете?


G_>>>>2) если возможностей VCL не хватает — можно переопределить оконную процедуру и обрабатывать самостоятельно специфические Windows-сообщения или использовать методы со свойством message.
А>>>Но нету PreProcessMessage
G_>>Я же говорю:
kuj>PreProcessMessage позволяет обработать сообщение непосредственно перед dispatch.

Я не понимаю о чем Вы.


G_>>>>компьютере занимает _ПАРУ СЕКУНД_.
А>>>Э-э... Это на проекте, которому уже 4 года? Позволю себе не поверить.
G_>>Только что сделал полный build проекту. Первый раз — 15 секунд. Последующие build (_build_!) — 2-3 секунды (потому как все попало в кеш видимо).
G_>>Напоминаю — build: полное перепостроение всего кода. Размер результирующего приложения: 2253824 байта.
G_>>Общий размер всех pas файлов в проекте — 1.096.671 байт.
kuj>1MB для всех файлов? Так это ма-а-ахонький проектик. Как Вам удалось растянуть его на 4 года?


Ваш проект?


G_>>>>С++ — не модульный язык. Даже включив всякие оптимизации компилирования, я очень долго __жду__ Это плохо.
А>>>Плохо то, что ты не знаешь, что такое "модульный язык". Тут дело в другом — компиляторы C++ двупроходные.
G_>>Под модульным в данном случае я подразумеваю схему компиляции и линковки.
kuj>Модульная схема компиляции и линковки? А как это?

C++ компилирует файлы, Delphi компилирует модули.


G_>>>>А Дельфи замечательно переваривает большие проекты (скажем, сейчас у меня в проекте 118 юнитов из них 58 форм) — _никаких_ _тормозов_. Это замечательно.
А>>>По секрету скажу, что 58 форм и 118 юнитов — это *не*большой проект. Ну разве что средний размер одного юнита у тебя — 1MB
G_>>Ну все относительно конечно Мой предыдущий большой дельфийский проект насчитывал более 100 форм. А каков Ваш наибольший проект?
G_>>Или это из серии "я видел людей которые видели людей которые видели Ленина"?
kuj>Большие проекты насчитывают сотни мегабайт исходного кода (только кода, заметьте).

Ясно. Т.е. вы как раз и есть тот самый, который видел людей, которые видели проекты?


G_>>>>4) Удобная среда, есть все что нужно и работает быстро.
А>>>Удобная среда заканчивается там, где заканчивается мышевозня, то бишь при выходе из дизайнера форм (который, кстати, тоже далеко не идеален — есть и более интересные решения).
G_>>Аргументы?
kuj>Навскидку:
kuj>1. Гайдлайны в дизайнере форм MFC/ATL/WTL.

Это чего такое?

kuj>2. Layout manager`ы в дизайнерах форм Java, .NET

Я бы поспорил насчет того, что жутко удобны. Но в любом случае, что мешает написать самому на Delphi подобную вещь? Delphi легко позволяет
делать подобные вещи.

kuj>3. Размещение невизуальных компонентов вне пределов формы на отдельной специально предназначенной области в дизайнере форм VS.NET

Мне наоборот это кажется неудобным.

kuj>4. Локинг элементов на форме там же.

Это такая защита от дрожащих рук?

kuj>5. Удобный визуальный tab ordering в дизайнере форм MFC/ATL/WTL.
kuj>...

В Delphi — правый клик на форме, выбрать Tab Order...


G_>>2) инлайн... ну да, наверное. тем не менее на Дельфи можно писать полностью ассемблерные процедуры с минимальным overhead, что может и отменит необходимость в инлайн.
kuj>Ассемблерные вставки ухудшают читабельность кода и являются потенциальным глюкодромом, не избавляя тем не менее от overhead`а. В C++ компилятор сам может догадаться проинлайнить тот, либо иной метод.

Это спорное утверждение, я не согласен.


G_>>>>Вообщем, надеюсь главная мысль ясна. Дельфи — замечательная "обертка" для проекта под Windows, он легко "тянет" и маленькие, и большие проекты.
А>>>Маленькие, да, тянет. Большие... — разве что у мазохистов/энтузиастов.
G_>>Аргументы?
kuj>Назову один, но весьма-весьма весомый — в Delphi отсутствуют smart pointers/garbage collector.

Ну не совсем так... Скажем строки (string) — это как раз пример smart pointer с подсчетом ссылок.

G_>>Да я не о том, что кому принадлежит. Я к тому, что .NET вобрала в себя лучшее и безусловно будет доминировать.
kuj>VB, C++, Java безусловно доминировали до создания .NET Да и сейчас, впрочем, Java и C++ доминируют.

Я говорю о длительном перспективе, маркетинг MS всех покроет(


G_>>as и is — не обязательно "костыль"
G_>>Простейший пример — обход контролов на форме с целью прописывания только лейблам какого-то свойства.
G_>>Простой, наглядный код с as и is. (а не static_cast<label> и пр.)
kuj>А зачем в этой задаче static_cast? В таком случае действительно удобнее было запросить у формы коллекцию этих объектов и пройтись по коллекции оператором foreach. Например, так:

kuj>

kuj>foreach(Label label in MyForm.Controls["Label"]) 
kuj>{
kuj>    label.Text = label.Name;
kuj>    ...
kuj>}
kuj>

Ну хорошо, пусть теперь нужно еще и кнопкам что-то подправить)

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

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


Я тоже заметил, что в теории программирования все всегда просто. Взять алгоритм да и внедрить его.
Откуда берутся глючные программы совершенно непонятно...)


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

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

Вот это и плохо. Borland обязана была что предпринять на эту тему.


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

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

Что конкретно плохо в STL и чем она вас не устраивает?

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

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

Спасибо за инфу, но это все таки хеш. А нужно AVL-дерево или аналог.

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

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

Порядок строк важен!

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

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

У них нет конструктора/деструктора. Это просто выделить кусок памяти с именованными полями на стеке.


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

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

Да, действительно.

Немного отступая от темы — непонятно зачем вC# делать так неудобно????? Это совместимость с какой-то предыдущей OLE-байдой?
Почему нельзя было для любого класса просто дернуть деструктор вместо наследования IDisposable, переопределения двух методов и пр.
Я не понимаю...


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

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

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

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

Как бы не вышло опять гладко в теории, а на практике...

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

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

Угу.


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

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

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


Я честно говоря не понял — какой кайф? Хочешь .NET — берешь VS .NET + C# и пишешь. Хочешь нейтив код — берешь Delphi 7 и пишешь.
Смысл появление Delphi .NET от меня ускользнул...Ведь и так можно в C# запускать нейтив код...
Создать очередную всеобъемлющую супер-пупер-унаследованную библиотеку классов?
Не понял я...

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

A>>Жаль только что нет
A>>nested constants

AVK>Это есть.

А что это такое? константы вложенные в константы? Даже представить такое себе не могу

С Уважением, Andir!

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

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

G_>У них нет конструктора/деструктора. Это просто выделить кусок памяти с именованными полями на стеке.

У object есть.

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

G_>Да, действительно.

G_>Немного отступая от темы — непонятно зачем вC# делать так неудобно?????

Потому что GC

G_>Это совместимость с какой-то предыдущей OLE-байдой?

Нет

G_>Почему нельзя было для любого класса просто дернуть деструктор

Потому что деструктора нет.

G_> вместо наследования IDisposable,

Реализации, не наследования.

G_> переопределения двух методов

Каких двух методов?

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

G_>Это не в тему, вообще-то. Но зачем кричать про революционные идеи в .NET

Вот ведь забавная штука — этот аргУмент я слышу регулярно. Где в этом топике кричали про революционные идеи .NET?

G_>, если a) _НИЧЕГО_НОВОГО_ в .NET нету. _Н И Ч Е Г О_.
G_>b) в .NET нет ни одной идеи, которая была _придумана в MS_.

Ну и? Что дальше?

G_>Понимаете? Маркетинговый шум вокруг .NET совершенно не соотвествует содержанию .NET

Ха, маркетинговый шум вобще очень редко соответствует действительности, давно пора это понять. Но мы ведь не маркетинг обсуждаем, не так ли?

kuj>>PreProcessMessage позволяет обработать сообщение непосредственно перед dispatch.

G_>Я не понимаю о чем Вы.

Можно обработать сообщение до того как оно попало в WndProc конкретного окна.

kuj>>Модульная схема компиляции и линковки? А как это?

G_>C++ компилирует файлы, Delphi компилирует модули.


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

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

A>>>Жаль только что нет
A>>>nested constants

AVK>>Это есть.

A>А что это такое? константы вложенные в константы? Даже представить такое себе не могу

Константы внутри методов.

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

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

NF>>А зачем допускать ошибки?!

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

VD>А. Ну, ну. Люблю смотреть на таких смелых в ночь после установки новой версии заказчикам.
Что ж. Можно поверить, что Вы действительно видели множество таких людей... Но это уже не является проблемой языка, а топик, если вспомнить, как раз направлен на обсуждение языка, а не человеческих особенностей.
NF>> А по стабильности C++ как раз на первом месте.

VD>Смешно.
Возможно. Но говорить о нестабильности языка, имея в виду невнимательность программиста... Это, на мой взгляд, неправильно.
NF>> Хотя, настоящий художник может сделать кистью шедевр, а неуч только загадит холст...

VD>Ага а трепач можеть все... но только на словах.
Хочу заметить, что я не допускал оскорблений. Это был просто пример. Если он расценен неправильно, то извиняюсь.

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

G_>Спасибо за инфу, но это все таки хеш. А нужно AVL-дерево или аналог.

Ты говорил про мап. Мап самым эффективным образом реализуется на хэш-таблице.

С деревьями у борланда фигово.

G_>Порядок строк важен!

А два листа чем не устраивают?

G_>У них нет конструктора/деструктора. Это просто выделить кусок памяти с именованными полями на стеке.

А что толку в деструкторах в Дельфи? Один фиг вручную вызывать.


G_>Немного отступая от темы — непонятно зачем вC# делать так неудобно????? Это совместимость с какой-то предыдущей OLE-байдой?
G_>Почему нельзя было для любого класса просто дернуть деструктор вместо наследования IDisposable, переопределения двух методов и пр.
G_>Я не понимаю...

Да в общем то сложности никакой нет. Метод переопределят нужно только один.

А почему нет деструктора... Сдается мне это в погоне за чистотой языка. В общем, догмы. Хотя имея трехлетний опыт программирования на Шарпе могу со всей отвественностью заявить, что проблем в этом нет никакий. Финализация нужна крайне редко. И гед она нужна обычно достаточно using-а.

G_>Как бы не вышло опять гладко в теории, а на практике...

Да вот как бы от Дельфи в свое время мы отказались в виду ужасного количества глюков в ВЦЛ-е (еще во времена 4-ой версии), а дотнет вроде как удовлетворяет.

G_>Я честно говоря не понял — какой кайф? Хочешь .NET — берешь VS .NET + C# и пишешь. Хочешь нейтив код — берешь Delphi 7 и пишешь.

Ну, если ты в основном писал на Дельфи, то кайф в том что не нужно переучиваться.

G_>Смысл появление Delphi .NET от меня ускользнул...Ведь и так можно в C# запускать нейтив код...
G_>Создать очередную всеобъемлющую супер-пупер-унаследованную библиотеку классов?
G_>Не понял я...

Думаю, что решение о переводе Дельфи на дотнет было принято не от болды. Скорее всего ребята поняли, что МС серьезно переориентируется на него и решили не упускать шанса.

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

G_>Я тоже заметил, что в теории программирования все всегда просто. Взять алгоритм да и внедрить его.
G_>Откуда берутся глючные программы совершенно непонятно...)

А это из-за велосипидистов. Не хотят они взять чужой алгорим, а хотят сами по граблям полазить.

G_>Вот это и плохо. Borland обязана была что предпринять на эту тему.

Ну, а без Борланда, что трава не расти? Что только в Борланде грамотные программисты есть?

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

G_>Что конкретно плохо в STL и чем она вас не устраивает?

Да многим. Есть не продуманные интерфейсы, как у мап-а. Не нравится странные названия многих методов. Не нравится, что что коллекции не имеют полноценного набора методов (все в отдельных функциях). Не нравится примитивность коллекций (могли бы реализовать и блее продвинутые вещи вроде Б+-деревьев и хэш-таблиц, хотя в нестандартных расширениях кое-что есть.)

Да и собственно я то не показатель. Но наличие коллекций почти в любой серьезной библиотеке, уже говорит само за себя.

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

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

Дело в том, что "опыт" — это не магический кристал вырастающий с годами. Опыт — это стимул подталкивающий к осуществлению действий гарантированно приводящих к меньшему кличеству ошибок. Иными словами это стимул приводящий к применению патернов, применение которых позволяет уменьшить количество ошибок.

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

К сожалению в С++ таких среств маловато, а грабель приводящих к ошибкам достаточно.

VD>>А. Ну, ну. Люблю смотреть на таких смелых в ночь после установки новой версии заказчикам.
NF>Что ж. Можно поверить, что Вы действительно видели множество таких людей... Но это уже не является проблемой языка, а топик, если вспомнить, как раз направлен на обсуждение языка, а не человеческих особенностей.

Гы. Я действительно видел не мало "таких" программистов. И что характерно — это самые обычные (а то и очень даже талантливые) программисты.

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

Самое смешное, что нововведения в этих языках банальны. Они направлены на увеличение типобезопасности и на устранение граблей. Результатом таких изменений является значительное сокращения общего (включающего время на отладку) времени разработки. И это проверенный факт.

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

Говорить нужно о нестабильности програм написанных на языке, а не о нестабильности языка. Но это так о точности терминологии.

Что же касается сути, то как раз не верно, причем в корне, полагаться на внимательность человека. Ему и так хватает проблем. Если можно снять с него часть проблем, то это нужно делать. Так как мозг — это тонкий инструмент причем очень дорогой и использоват его лучше там где он может дать нибольший эффект.

К тому же стабильность — это не только минимум ошибок. Ошибок может быть мало, но их последствия могут быть непоправимы. Например, ошибка в безопасном управляемом коде приводить к исключению причем гарантируется, что при этом не произойдет порчи памяти и т.п. Таким образом банальная обработка ошибок может избавить от необходимости перезапускать приложение и спасет от потери данных.

Изумитльный пример проблем языка — МС Ворд. Он глючит на протяжении всего срока своего существования и программисты МС ничего не могут с этим поделать. А ведь у МС бабок и хороших программистов выше крыши.

VD>>Ага а трепач можеть все... но только на словах.
NF>Хочу заметить, что я не допускал оскорблений. Это был просто пример. Если он расценен неправильно, то извиняюсь.

А я кстати, не указывал, на то что тут кто-то лично трепачь. Все ассоциации каждый делат сам. И если тебе показалось, что твои слова несколько натянуты, то может быть пролема именно вних?

Ладно, не принимай близко к сердцу. Но заявления твои столь же не верны как и безопеляционны. А это не есть гуд. Сомнения — это не стыдно. Без них не может быть найдено верное решение.

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

S> Ага наверное логичнее сравнивать Delphi/Net/Java vc C++. Так как у Net и у Delphi на много больше схожего и дельфисты в Net и Яве как рыбы в воде, чего не скажешь о сишниках.

Остается только один вопрос... Почему те кто освоили Delphi, .Net, Java и C++ очень часто называют себя именно сишниками?

В общем, кончай говорить за других. Я тот самй сишник освоивший все что ты перечислил включая дотнет и чувствую себя в нем как рыба в воде.

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

kuj>построение "цепочек" делегатов (C++, мультиметод),

мультиметоды — это вообще-то немного другое. Это выбор метода на основании рантайм типа. Этого не в С++, не в Шарпе нет. Хотя эмулируется на базе патерна "визитор".

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

С++-то тут причем? В Билдере тоже много наворотов, но вот к С++ они отношение имеют очень отдаленное.