Вопросы по Delphi (3 стр)

g-cont
> А если я объект на стеке создаю? Всё равно будет в динамической памяти
> размещён?
на стеке будет указатель, а сами данные - в динамической памяти. Как в жабах\шарпах.
Есть правда еще легаси `object` - которые можно создавать на стеке, но их в VCL нет.

> Есть ли в делфи динамические массивы? Кто-то мне вроде говорил, что нету, но
> может я неправильно понял.
Динамические массивы - тоже по сути объекты (если говорить корректнее, то "ссылочный тип"), данные в хипе, работаешь с указателем. Всегда нумеруются с 0, создаются

data : array of Integer;
SetLength(data, 10);

удаляются автоматически по ARC.

> Тут вопросов нет. Но иногда в конце идёт приписка of object;
да, это ссылка на метод объекта. Внутри состоит из указателя на объект+указателя на функцию.

> Структуры в Delphi являются аналогом структур в Си? Там нельзя объявлять функции или классы?
В новом дельфи можно, но в любом случае виртуальных методов и наследования у них нет.

> Вроде как это опциональный модификатор с которым дедуктор становится умнее что
> ли. Ну я так это понял из корявого описания в учебнике.
Без него компилятор будет ругаться если увидит в одном модуле\объекте две функции с одинаковым именем. С ним - не будет при условии что у них разные типы.

g-cont
Объявление на Delphi

TTest = class(TObject)
end;

будет выглядеть на C++ как

class TTestHidden : public TObjectHidden
{
};
typedef TTestHidden *TTest;

где TTestHidden недоступен программисту, можно объявлять только переменные типа TTest.
Полным аналогом при этом не является, т.к. на Delphi VMT объектов доступна для работы с ней:

Т.е. с точки зрения C++ в TTest.Test скрытым аргументом передается VMT класса TTestHidden, а в C++ я не припоминаю стандартного способа работы с VMT класса.

При этом в VMT могут быть как виртуальные методы класса, так и виртуальные методы самой VMT:

Ну и VMT не вполне корректное название, помимо таблицы виртуальных методов там есть другие метаданные связанные с классом.

Объявить на стеке тоже можно, но непрактично:

CD
> а в C++ я не припоминаю стандартного способа работы с VMT класса.

Такого как в Delphi там и близко нет.
В Delphi классовые объекты могут иметь виртуальные функции и в наследуемых классах и формально являются синглтонами которые наследуются не от TObject, а от TClass, при этом имя класса и есть имя синглтона со всеми вытекающими.
Виртуальные конструкторы как пример. Удобная штука.

g-cont

В Delphi объекты это ссылочные типы как в Java или C#, т.е. всегда создаются в куче и переменные их типа есть только ссылки (указатели) в эту кучу.

g-cont   
> Я пишу конвертор исходного кода Delphi->C++ чтобы не учить язык
Возьми BNF Pascal-я, сэкономишь время

> Виртмашина на С++ написана, с синтаксисом С++
Есть же LLVM

> Но иногда в конце идёт приписка of object;
> Т.е., как я понимаю указатель на функцию, являющуюся членом произвольно класса?
Да. Используется для обработчиков event-ов, которые указатели на функции и их можно переприсваивать

> Структуры в Delphi являются аналогом структур в Си?
Да.

> Там нельзя объявлять функции или классы?
Нельзя, для последнего есть object, которые также аналог структур, но с методами и может выделяться на стэке. Однако VCL весь сделан через class

>reintroduce
g-cont
> Это когда метод в наследнике принудительно выбрасывают из vtable?
как бы нет.
старый метод остаётся в таблице, но более не получает своего продолжения, и заменяется новым.
(т.е. наследники от класса, который сделал "reintroduce" могут переопределять только уже новый метод).
И "reintroduce" метод может поменять сигнатуру (добавить/выкинуть параметры)

kipar
> reintroduce, но в исходниках vcl он вроде не встречается

пример использоваться "reintroduce" из vcl-а

Есть тип TControl, который описывает поведение некого контрола, если на контрол "нажали"

class
  TControl = class
    procedure Click; virtual;
  end;
  TButton = class(TControl)
    procedure Click; override;
  end;

классический такой ООП. всё скучно и понятно.

НО! есть ещё контрол который реализует в себе сразу две кнопку TUpDown.

И для него существующий "click" не подходит, т.к. нехватает информации на какую именно часть нажали.
По-этому, для него метод "click" был переорпеделён:

  TCustomUpDown = class(TControl)
     procedure Click(Button: TUDBtnType); reintroduce; 
  end;
  TUpDown = class(TCustomUpDown)

и теперь любой наследник, от TCustomUpDown может override-ить Click(TUDBtnType), но не Click() который был от TControl.

с другой стороны, если я скастую TUpDown к TControl. (и я имею полное право на это, тк TUpDown наследник от TControl), то вызывать "новый click", я уже не смогу, и могу вызывать только "старый"

  TControl(updown1).Click();

В наши дни, такой подход принято считать говноорхитектурой, потому что в методе "Click" в принципе мало полезной информации. А если бы ты там передавалась дополнительная информация, то и "reintroduce" бы не понадобился.
Либо надо использовать композицю, тогда для "up" и "down" есть два вложенных контрола в TUpDown...

По-этому "reintroduce" используется не часто, но он есть.

g-cont
> Как устроены массивы в делфи?
как имхо, для тебя гланвые вилы, это строки.
т.к. строки в delphi - ARC и copy-on-write
я хз, если что-нить из коробки в крестах для такого поведения.

skalogryz
> я хз, если что-нить из коробки в крестах для такого поведения.

Проблем быть не должно. ARC+CoW это просто схема оптимизации которая оптимизирует то оптимизирует, но внешне для программиста выглядит так же как ведёт себя в крестах обычный std::string.

=A=L=X=
> Проблем быть не должно. ARC+CoW это просто схема оптимизации которая
> оптимизирует то оптимизирует, но внешне для программиста выглядит так же как
> ведёт себя в крестах обычный std::string
Буду держать кулачки, за то, чтобы кресто версия оказалась тормознее дельфийской, если цель состоит именно в портировании кода с делфи на кресты.

skalogryz, сколько у тебя (по моему мнению) бесполезной информации в голове... Для этого должна быть спецлитература, которую посмотрел, увидел , понял и забыл.

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

Mirrel
> сколько у тебя (по моему мнению) бесполезной информации в голове...
я продукт своего времени. голова загажена непонятно чем.

Mirrel
> 1. По сути, вообще переписывать с одного ЯП на другой не вижу смысла.
> 2. Проще заново реализовать всё самому, чем перековыривать чужой код
у тебя "переписывание с одного ЯП на другой" следует из второго утверждения.
собственно топиккастер с тобой согласен:
g-cont
> Я пишу конвертор исходного кода Delphi->C++ чтобы не учить язык. Возникла такая необходимость.

skalogryz, в одном случае это не очень хорошо. В другом случае...

Когда я варил ZenGL под MacOS я перелопатил их документацию, более-менее разобрался что к чему и "выбросил" это как не нужный хлам (понятно дело, что если я ещё раз это буду делать, то сделаю быстрее, потому что знаю где и что искать).
Но вот... свой код... твою дивизию, его же я писал... комментировал. И забыл...
В таких-то случаях не очень хорошо. Перебираешь некоторые места и такое ощущение, что заблудился. )))

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

Mirrel
> надо всё на бумагу выкладывать, так хоть более визуально информативнее.

>>на стеке будет указатель, а сами данные - в динамической памяти. Как в жабах\шарпах.
Это конечно сугубо моё IMHO, но когда язык абсолютно все объекты размещает в динамически выделенной памяти - это первый признак архитектуры виртуальной машины. Конечно не единственный и не достаточный, но тем не менее. Зачем мне для АТД каждый раз звать маллок, ну бред же.

>>да, это ссылка на метод объекта. Внутри состоит из указателя на объект+указателя на функцию.
Правильно понимаю, это для того чтобы дёргать методы объекта из глобального неймспейса? Там нечто вроде static функции из которой уже вызывается каллбэк объекта, ну т.е. то, что в крестах каждый раз приходилось ручками писать или лепить макрос.

>>С ним - не будет при условии что у них разные типы.
Имеются в виду типы и кол-во аргументов ведь?

>>class procedure Test; //имеет скрытый аргумент Self типа TTestVMT
Ну понятно, в С++ этот "скрытый" аргумент придётся просто вручную прописать.

>>Однако VCL весь сделан через class
Ну и хорошо, будет мне меньше работы :)

>>как имхо, для тебя гланвые вилы, это строки.
Кстати нет. У меня в VM stringtable с уникальными идентификаторами и временными строками, если присвоение на стеке, тут нет проблемы.

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

>>Проще заново реализовать всё самому, чем перековыривать чужой код
У меня нет должного опыта в конструировании архитектуры визуальных форм. Придётся эти классы окошек 10 раз переписывать, добавляя недостающий функционал. А в Делфи такая удобная проверенная временем VCL. Которая идеально ляжет на мою VM. Конечно на чистый С++ я бы и пытаться не стал повторить этот фокус, получилось бы очень костыльно.

Кстати, в С# вроде бы библиотека визуальных компонентов ведь тоже максимально похожа на VCL или нет?

g-cont
> Это конечно сугубо моё IMHO, но когда язык абсолютно все объекты размещает в
> динамически выделенной памяти - это первый признак архитектуры виртуальной
> машины.

Это всё не про Delphi. Когда Borland сделали Object Pascal (предшественник Delphi) они добавили к него объекты определяемые ключевым словом object которые были максимально похожи внутренне на структуры record. Это всё value-type и до сих пор доступны в Delphi.
Однако, имхо, помыкавшись с object-ами они созрели ООП с человеческим лицом и сделали ключевое слово class и ссылочную семантику объектов нового поколения.
Она в первую очередь преследует ООП-нутость на всю голову. Но действительно похоже на всякие Java где все объекты наследуются от единого и неизбежного предка TObject.

> Кстати, в С# вроде бы библиотека визуальных компонентов ведь тоже максимально похожа на VCL или нет?

Так главный дизайнер Delphi ушёл в Microsoft и начал тогда создавать как раз C#.
Главные фичи которая делает визуальные библиотеки Delphi и C# схожими иделогически - это делегаты (указатели на методы) и свойства обмазанные мощной интроспекцией.

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

Методы объекта класса похожи очень на статические функции, но метакласс (наследник TClass) реально существует как сущность и у неё могут быть и виртуальные методы тоже и метаклассы образуют ту же иерархию наследования чтобы и описанные на них классы.
Если все объекты в конечном итоге наследуют от TObject, то все объекты класса наследуют в конечном итоге от TClass и при этом TObject как идентификатор имеет тип TClass.

g-cont
> Правильно понимаю, это для того чтобы дёргать методы объекта из глобального
> неймспейса?
не обязательно из глобального, просто чтобы в качестве скажем каллбека на нажатие кнопки или на завершение операции указать не просто статическую функцию, а конкретный метод объекта (`Form1.OnButton1Click` \ `CurObject.OnComplete`).

skalogryz
> можно, что-то типа такого:
Зачем? Есть же:

TMySingle = class
private
  class var FClassField1: Integer;
  class var FClassField2: Boolean;
public
  class function Foo(): Boolean;
  class procedure Bar();
  class constructor Create;
end;

Чем не синглтон?

g-cont
> Это конечно сугубо моё IMHO, но когда язык абсолютно все объекты размещает в
> динамически выделенной памяти - это первый признак архитектуры виртуальной
> машины.
Ну язык не все объекты размещает на куче. Есть же record (аналог struct). Это value типы, и они на стеке создаются.