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

[archimed7592]

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

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

Не надо мне особой корректности. Сойдёт что-то вроде

var app, wb, ws:variant;
begin
app = CreateObject('Application.Excel');
wb = app.Workbooks.Add;
ws = wb.Worksheets[1];
ws.Range('B7').Value = 99;
ws.Range('A3').Value = 'abc';
end.

Подкорректируйте до работоспособности.
Если форматная строка такая проблема, то можно ничего не форматировать.

[--Ins--]

Цитата

Язык - некий абстрактный набор правил. Компилятор - конкретный инструмент, позволяющий создавать продукт с использованием языка.

Кстати, если раньше Delphi - подразумевал IDE и компилятор, а язык назывался Object Pascal, то теперь Delphi - это еще и название языка. К компилятору у меня у самого есть масса претензий, однако к языку - значительно меньше

[Romkin]

Цитата linuxfan @ 11.03.08, 12:20

Ты должен явно писать pCh := @s[1] (или @s[0], не помню, православная у них индексация строк или языческая).

Вообще говоря, надо просто писать

procedure foo(s: string);
var pCh: PChar;
begin
  pCh = PChar(s);
  Inc(pCh);
end;

и счетчик не шевельнется: программист явно преобразовал тип, таперича он отвечает за последствия. Впрочем, в данном отрезке ничего страшного и не произойдет.

Добавлено 11.03.08, 12:30
archimed7592, примерно так:

var app, wb, ws:variant;
begin
app = CreateOLEObject('Application.Excel');
wb = app.Workbooks.Add;
ws = wb.Worksheets[1];
ws.Cells[2,7].Value = 99;
ws.Cells[1,3].Value = 'abc';
end.

И что дальше?

[--Ins--]

Цитата

archimed7592, примерно так:

Только знак присваивания у тебя фашистский стоит

[archimed7592]

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

Никак. Потому что это - не скомпилируется

А как сделать, чтобы компилировалось? Т.е. взять PChar от произвольной строки? Ах, да, наверное написать PChar(s) .

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

Думаю, что есть Но даже если нет - это не дает тебе право проводить между языком и компилятором знак равенства Это два совершенно разных понятия. Язык - некий абстрактный набор правил. Компилятор - конкретный инструмент, позволяющий создавать продукт с использованием языка.

Это очень верное суждение, но... не в нашем случае .
На примере с С++: есть Стандарт(Его Величество), а есть куча разных компиляторов - т.н. conforming implementation. Но не все из них conforming - скажем, Borland C++ Builder 6 сильно далёк от стандарта(из-за своей древности). Т.о. если ты будешь критиковать конкретно BCB, то я скажу тебе выкинь BCB и обрати взор на Стандарт - там то-то и то-то можно делать так-то и так-то.
В твоём же случае стандарта нет(чем вы нескромно гордитесь), но есть некотороая Language Specification(или Reference), котороая описывает все ньюансы языка. И там, со слов Ромкина, явно написано "для увереной работы as необходимо снабжать интерфейсы IID'ами". Т.о. если я захочу написать альтернативный Delphi, то я буду руководствоваться именно этими словами, и мой компилятор будет иметь все те же плохие черты, что и оригинал.
И, если уж говорить о языке, то не кажется ли тебе, что все компиляторы для этого языка должны работать одинакого(по крайней мере в рамках спецификации), как это, например с С++?

[Romkin]

Цитата Flex Ferrum @ 11.03.08, 12:22

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

Тем, что нестандартно и вынуждает программиста явно работать с данной реализацией. Почему не применили имеющуюся реализацию?

[--Ins--]

Цитата

Т.о. если я захочу написать альтернативный Delphi, то я буду руководствоваться именно этими словами

Руководствоваться - будешь, но тебе никто не запретит в совем компиляторе идентифицировать интерфейсы неявно Собственно некоторые языковые различия есть и в Delphi for Win32 и в Delphi.NET. В частности - в Delphi для Win32 в class helper ты не можешь объявить виртуальный метод, а в .NET - можешь А в более ранних версиях Delphi - вообще нет понятия class helper. Говорят же тебе - язык развивающийся.

[Flex Ferrum]

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

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

По нескольким причинам.
1. Либо так исторически сложилось.
2. Либо она могла не отвечать (по тем или иным причинам) требованиям задачи.
3. Либо по велению своей левой пятки.

[Romkin]

Цитата Flex Ferrum @ 11.03.08, 12:22

Ничего не понял. Кто на ком стоял? На псевдокоде можешь показать - что именно ты сделал?

ОК. Прмерно:

type
  IFoo = interface
  ['{3DFE8A08-9485-4F64-A95C-90E9CF9BDE30}']
    procedrue Proc1;
  end;
  IBar = interface
  ['{A666283E-9303-4657-9B61-E6880F580796}']
    procedure Proc2;
  end;
 
  TMy = class(..., IFoo, IBar)
    FBar: IBar;
    procedure Proc1; // явно реализуем IFoo
    property Bar: IBar read FBar implements IBar;
    constructor Create;
  end;
...
constructor TMy.Create;
begin
  FBar := <Чего-то>;
end;

Где чего-то - это создание класса, или загрузка библиотеки c вызовом процедуры, которая вернет указатель на IBar, или, наконец, coCreateInstance. Области видимости я проигнорировал
После этого последнего телодвижения у меня получился объект, реализующий IFoo и IBar, то есть, нет проблем:

var
  Foo: IFoo;
  Bar: IBar;
begin
  Foo := TMy.Create;
  Foo.Proc1;
  Bar := (Foo as IBar);
  Bar.Proc2;

Прошу заметить, что все, что должно быть известно - это описание интерфейса с IID и способ, как его получить.

[--Ins--]

Цитата

В твоём же случае стандарта нет(чем вы нескромно гордитесь),

И я думаю - это правильно. Так как если введение стандарта будет иметь смысл - уверен, это будет сделано. На данный момент в этом смысла мало, так как отрасль у нас молодая, бурноразвивающаяся. Если язык не будет успевать с ней в ногу - он устареет и умрет. Вводить стандарт - это тормоз в развитии языка. И делать это "для галочки" по меньшей мере глупо. Это все равно, что взять лопату и копать себе могилу.

[Flex Ferrum]

Цитата Romkin @ 11.03.08, 13:06

Прошу заметить, что все, что должно быть известно - это описание интерфейса с IID и способ, как его получить.

Понятно. Еще один привет от технологии COM - а именно, реализация COM Aggregation. Знаем такое. В С++ такое тоже возможно, правда для этого совсем не обязательно явно наследоваться от интерфейса, реализуемого через агрегат. А сколько при этом остается за кадром - это мама дорогая... Куда уж тут zero-cost features...

Добавлено 11.03.08, 13:19
Плюс, конечно, в том, что вам не приходится при этом заморачиваться со всякими inner- и outer-объектами, синхронизации контроля времени жизни (дело в том, что AddRef, выполняемый для полученного таким образом интерфейса Ibar должен выполняться для объекта TMy, Release, соответственно, также). Ну и т. д. Приколов тут очень много - мелкомягкие постарались.

[--Ins--]

Цитата

реализация COM Aggregation

А что, агрегация вне технологии не имеет смысл?

Цитата

правда для этого совсем не обязательно явно наследоваться от интерфейса

Ну и в Delphi в общем-то не обязательно. Можешь для QueryInterface написать свою реализацию. Но в Borland на этот счет о нас уже позаботились.

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

Цитата

Ibar должен выполняться для объекта TMy

Все верно. Тут нужно либо самому вложить такое поведение в агрегат (не путаю термины?), либо унаследовать его от TAggregatedObject, где все это уже реализовано.

[Flex Ferrum]

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

А что, агрегация вне технологии не имеет смысл?

Имеет, конечно, но, я думаю, ноги растут именно оттуда. Подозреваю, что при этом inner-объекту делается специальный вызов CoCreateInstance (с ненулевым параметром pOuter), и прочее. Что, кстати, с точки зрения языка лишено смысла, т. к. реализацию интерфейса посредством композиции (на языковом уровне) можно реализовать и иначе. Ибо в данном случае класс, реализующий интерфейс, совсем не обязан быть CoClass'ом (что требуется для корректной работы CoCreateInstance). Ну и прочее...

[Romkin]

Цитата Flex Ferrum @ 11.03.08, 13:16

Еще один привет от технологии COM - а именно, реализация COM Aggregation.

Да. Только я не подключаю СОМ, если работаю с внутренним объектом. И почему именно СОМ aggregation? Delphi aggregation!

[Flex Ferrum]

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

(не путаю термины?)

В данном случае проще оперировать терминами inner и outer. Так понятнее.

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

Цитата Romkin @ 11.03.08, 13:30

И почему именно СОМ aggregation?

Потому что

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

Все верно. Тут нужно либо самому вложить такое поведение в агрегат (не путаю термины?), либо унаследовать его от TAggregatedObject, где все это уже реализовано.

Реализовать это на уровне языка можно и более прозрачным способом.

Добавлено 11.03.08, 13:32
Видишь, я даже не зная деталей того, как это непосредственно реализовано в Delphi, "бью в яблочко" своими предположениями. Догадайся с трех раз - почему?