Delphi vs C++ , Часть 1

ISC, объясни мне тогда причину появления языка C#? А языка PHP? Чем стандартный C++ тут не подходил?

Цитата Romkin @ 11.03.08, 12:46

вынуждает программиста явно работать с данной реализацией.

Нет, не вынуждает.

Цитата Romkin @ 11.03.08, 12:46

Почему не применили имеющуюся реализацию?

Ладно, как обещал, упомянутые мною реализации строк:
1. Стандартная. Ну, она и в Африке стандартная.
2. STLport. STLport - это замена почти всей стандартной библиотеки С++(как правило, в лучшую сторону). В т.ч. и реализации строк. BTW, реализация STLport - одна из самых шустрых.
3. Qt. С Qt история такая: Qt может использоваться на платформах на которых нет STL(да, бывает и такое кастрированное environment), соответственно Qt предоставляет собственную реализацию строк. BTW, она предоставляет ещё и QVector, QMap, QSet and so on.
4. ICU. International Components for Unicode - есть как для Java, так и для С++. Эта реализация полезна для работы с разными кодировками, но, если ничего не мешает, то можно исползовать эту реализацию как основную, особенно учитывая возможности i18n.
5. Про CString меня не спрашивайте - я её не упомянал и не использую(как и MFC в целом). Ничего не забыл?

Цитата --Ins-- @ 11.03.08, 12:51

Руководствоваться - будешь, но тебе никто не запретит в совем компиляторе идентифицировать интерфейсы неявно

Вот здесь то ты и ошибаешься . Смотри, я сделал так, что интерфейсы будут работать как полагается без UIID'ов. Отлично, написал Вася Пупкин тысячи строк кода используя мой компилятор. И вот, в один прекрасный день ему захотелось откомпилировать компилятором от Borland(к примеру, потому, что он делает более быстрый код) - а хрен бы там. Откомпилировать он сможет, ибо в другом компиляторе интерфейсы без UIID кастрированы. Иначе говоря, компилятор может предоставлять кучу расширений языка, но это будет именно расширениями и к языку отношения не имеют(пример: closure из BCB). Что же касается UIID'ов - это недостаток языка, а не расширение компилятора .

Цитата Romkin @ 11.03.08, 12:26

И что дальше?

А дальше вот что .
Скажи мне любезный, сделал я свою технологию ELO/MOC(OLE/COM задом наперёд) и захотел добавить в любимый язык(Delphi) такие же шикарные возможности, чтобы можно было проделать то же самое, но ориентируясь на мои новые технологии ELO/MOC.
1. Это возможно?
2. Это возможно без хаков над языком/компилятором?
3. Это возможно реализовать на Delphi или понадобится внешняя прослойка на С/C++?

Добавлено 11.03.08, 14:13

Цитата --Ins-- @ 11.03.08, 13:50

Не идет оно в разрез. Строки и динамические массивы - также типы с автоматическим управлением памяти.

Славно, как мне реализовать 3-юю(4-ую, 5-ую, ... N-ую) сущность с автоматическим управлением памяти?

Цитата archimed7592 @ 11.03.08, 14:09

1. Это возможно?
2. Это возможно без хаков над языком/компилятором?
3. Это возможно реализовать на Delphi или понадобится внешняя прослойка на С/C++?

1,2 - да. Если речь идет о вариантах с поздним связыванием.
3. А это уже зависит от того, как реализуешь. Ты должен дать способы работы, по меньшей мере - способы создания и вызова методов, которые я мог бы сделать из Delphi. Дашь - будет так же.

Добавлено 11.03.08, 14:20

Цитата archimed7592 @ 11.03.08, 14:09

Славно, как мне реализовать 3-юю(4-ую, 5-ую, ... N-ую) сущность с автоматическим управлением памяти?

1. Через интерфейсы
2. Через варианты.

Romkin, пример можно? Какой-нибудь примитивный. Чтобы:
1. я мог создавать объекты разного рода(типа Excel или AutoCAD) - т.е. выполняющие несколько разные ф-ции.
2. я мог вызывать разные методы этих объектов(как выше).
3. результаты всей этой эмуляции сохранялись бы в текстовый файлик.

Цитата --Ins-- @ 11.03.08, 14:00

ISC, объясни мне тогда причину появления языка C#? А языка PHP? Чем стандартный C++ тут не подходил?

Так то совсем другие языки. Это нормально...
Но так или иначе у них как понимаю есть тоже свои стандарты. Может не так явно публикуемые из-за меньшего отношения тех языков к низкоуровневому или системному программированию. Ведь, чем более широкого назначения язык, тем более его средства должны быть узаконены

Цитата Romkin @ 11.03.08, 14:14

1. Через интерфейсы
2. Через варианты.

Смотри, варианты, строки, дин. массивы и интерфейсы реализуют ref-counting. Т.е. 4 разных вида сущности. Я хочу добавить 5-й вид аля дин. число(для точных вычислений, к примеру), как мне это сделать?

Цитата archimed7592 @ 11.03.08, 14:23

Romkin, пример можно? Какой-нибудь примитивный. Чтобы:
1. я мог создавать объекты разного рода(типа Excel или AutoCAD) - т.е. выполняющие несколько разные ф-ции.
2. я мог вызывать разные методы этих объектов(как выше).
3. результаты всей этой эмуляции сохранялись бы в текстовый файлик.

То есть, предлагаешь мне реализовать что-то вроде СОМ? Не слишком ли?
Примера с комплексными числами тебе мало? В файл я их тоже могу и сохранить, и прочитать. Свойства и методы вызвать...

Добавлено 11.03.08, 14:36

Цитата archimed7592 @ 11.03.08, 14:26

Т.е. 4 разных вида сущности. Я хочу добавить 5-й вид аля дин. число(для точных вычислений, к примеру), как мне это сделать?

Ау! Реализация комплексных чисел тебя устроит?

Цитата archimed7592 @ 11.03.08, 14:26

Смотри, варианты, строки, дин. массивы и интерфейсы реализуют ref-counting. Т.е. 4 разных вида сущности. Я хочу добавить 5-й вид аля дин. число(для точных вычислений, к примеру), как мне это сделать?

За что мне нравицца C++, так это за малое число магических операторо-функций и эффектов

Romkin, ты не понял. Ок, более конкретно.
Есть два класса: Class1 и Class2.
Я должен мочь создавать объекты этих классов в неограниченном количестве(посредством ф-ции CreateELOObject).
Я должен мочь вызывать методы Foo и Bar класса Class1 и метод FooBar класса Class2. Причём, особенностью технологии будет то, что можно будет неспецифицировать кол-во аргументов для метода. Т.о. методы должны принимать все переданные аргументы и выводить их(в порядке передачи ) в текстовый файлик. Также они должны выводить что вызван конкретно этот метод(Foo, Bar или FooBar), имя типа(Class1 или Class2) и номер объекта(в порядке их создания). В идеале хотелось бы нечто более продвинутое: текстовый файлик classes.txt вида

ClassName1 DescriptorFileName1.txt
ClassName2 DescriptorFileName2.txt
ClassName3 DescriptorFileName3.txt

И соответствено файлы-описатели конкретных классов вида:

Foo
Bar

или

FooBar

Осилишь?

Добавлено 11.03.08, 14:47

Цитата Romkin @ 11.03.08, 14:32

Реализация комплексных чисел тебя устроит?

Ты её сам писал? Или она в язык встроена? Если сам, то устроит, конечно.

Цитата

Вот здесь то ты и ошибаешься

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

Цитата

Так то совсем другие языки. Это нормально...

Конечно нормально. Появилась новая технология - появился новый язык. Потому что изменить стандарт - это требует немалых усилий, куда проще новый язык придумать А если эта новая технология заместит старую, то язык уйдет в небытие А вот когда стандарта нет - язык проще адаптировать. Я же говорю, отрасль - молодая и бурноразвивающаяся, новые технологии будут появляться очень часто. Вот когда (если) ситуация утрясется - может и будет иметь смысл вводить стандарты на Delphi.

Цитата archimed7592 @ 11.03.08, 14:45

Ты её сам писал? Или она в язык встроена? Если сам, то устроит, конечно.

ДАется как пример того, что тебе надо. А задачи переписывания СОМ у меня еще не стояло.

Цитата --Ins-- @ 11.03.08, 14:48

А вот когда стандарта нет - язык проще адаптировать.

Чем проще то? А как будут обстоять дела с совместимостью?

Цитата

А как будут обстоять дела с совместимостью?

Пока никто не жалуется. Зато посмотрим, где будет твой C++ через 10 лет Уже очевидно, что для решения прикладных задач он как правило не является наиболее удобным инструментом. Только системные задачи он пока решает максимально эффективно. А задача системщиков - это обсуживание прикладников, так как погодой управляют последние

Цитата --Ins-- @ 11.03.08, 14:48

Ты рассуждаешь с той точки зрения, что язык стандартизован Это не так.

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

Цитата Romkin @ 11.03.08, 14:52

ДАется как пример того, что тебе надо. А задачи переписывания СОМ у меня еще не стояло.

Ну дык давай уже.
А COM - я тебя не прошу его переписывать, я лишь прошу показать мне что это возможно. К примеру, на С++ у меня на это ушло бы 15-20 мин.

Цитата --Ins-- @ 11.03.08, 15:00

Зато посмотрим, где будет твой C++ через 10 лет Уже очевидно, что для решения прикладных задач он как правило не является наиболее удобным инструментом.

Это до тех пор, пока не произойдет консолидация имеющегося для С++ набора библиотек, решающих те или иные прикладные задачи. Те же Delphi, Javа и C# хороши своими фрейморками. Как языки - они да, достаточно просты, но C++ (при существующем уровне информации о нем) не многим сложнее. В любом случае, сейчас вести разработку тех же desktop-приложений на нем не многим сложнее.