ООП, Обьекты и Классы

[and]

Кого - их? Object и record? Class и Object? Всех троих?

[Sergei I. Gorelkin]

Всех троих, при условии что они создаются динамически (record и object - с помощью new).

[VirtUX]

Код: Выделить всё

type
TAnyArr = array of Byte;
TAnyObj = object
  f1: TAnyArr;
end;
var Obj: TAnyObj;

Если я правильно понимаю, то Obj - находится в стеке при объявлении его глобально. Тогда вопрос: получается f1 имеет значение адреса в динам.памяти. До начала установки размера массива f1 = nil или там будет мусор стека?

[Sergei I. Gorelkin]

Все строки типа Ansi/Wide/UnicodeString, дин.массивы и интерфейсы инициализируются и финализируются компилятором вне зависимости от того, где они объявлены.

[and]

Всех троих, при условии что они создаются динамически (record и object - с помощью new).

То есть, в FPC New(pRec) по накладным расходам близко к Obj:=TObject.Create? ЗдОрово! Я в Delphi ушёл от классов к записям именно из-за существенной разницы в производительности.
Но изящества, естественно, сильно поубавилось.
Спасибо!!!

[Sergei I. Gorelkin]

По сравнению с Дельфи 7, в FPC:
- Пустые блоки try..finally оптимизируются напрочь, поэтому конструктор TObject.Create не содержит этого блока.
- Метод InitInstance просматривает предков класса в поисках реализованных интерфейсов только если известно, что они есть.
- Менеджер памяти пошустрее будет.

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

[Гость]

У меня вопрос. Я перевожу программу на FPC. Как мне быть с наследованием и приведением объектов?
К примеру:

Код: Выделить всё

type 
  TTest1 = packed object
    a: integer;
    procedure test(ai:integer);
  end;

  TTest2 = packed object (TTest1)
    b: boolean;
    c: byte;
    procedure test(ai:integer);
    procedure test2(ai:integer);
  end;

  TTest3 = packed object (TTest2)
    d: integer;
  end;


var
  tt1:TTest1;
  tt2: TTest2;
  tt3:TTest3;

1) как можно привести tt2 к tt1, т.е. получить что-то вроде:
tt1(tt2).a:=10;
в fpc это вызовет ошибку компиляции.
2) как передать в одну и ту же процедуру в качестве аргумента не только TTest1, но и TTest2, TTest3 и т.д.
3) как участок памяти привести к любому из вышеуказанных типов

[zub]

Код: Выделить всё

type 
  PTTest1=TTest1^;
  TTest1 = packed object
    a: integer;
    procedure test(ai:integer);
  end;
  PTTest2=TTest2^;
  TTest2 = packed object (TTest1)
    b: boolean;
    c: byte;
    procedure test(ai:integer);
    procedure test2(ai:integer);
  end;
  PTTest3=TTest3^;
  TTest3 = packed object (TTest2)
    d: integer;
  end;


var
  tt1:TTest1;
  tt2: TTest2;
  tt3:TTest3;

>>1) как можно привести tt2 к tt1, т.е. получить что-то вроде:
>>tt1(tt2).a:=10;
>>в fpc это вызовет ошибку компиляции.

Код: Выделить всё

TTest1(tt2).a:=10;

>>2) как передать в одну и ту же процедуру в качестве аргумента не только TTest1, но и TTest2, TTest3 и т.д.

Код: Выделить всё

procedure superproc(var obj:TTest1);
.........
superproc(tt3);

>>3) как участок памяти привести к любому из вышеуказанных типов

Код: Выделить всё

PTTest1(указатель)^;
PTTest2(указатель)^;
PTTest3(указатель)^;

должно быть както так

[Гость]

>>1) как можно привести tt2 к tt1, т.е. получить что-то вроде:
>>tt1(tt2).a:=10;
>>в fpc это вызовет ошибку компиляции.

Код: Выделить всё

TTest1(tt2).a:=10;

Ой-ё, вот это я ступил - в проекте имена типа и переменной совпадали, а при переносе на паскаль я имена типа поменял, а в приведении оставил как у переменной )))
По остальному благодарю, всё работает.

Добавлено спустя 8 минут 38 секунд:
Ещё вопросы, насколько допустимо приведение object к record и обратно и насколько object совместим с сишной struct.

Добавлено спустя 5 минут 48 секунд:
если определить

Код: Выделить всё

type
ttype1 = packed object
  a: integer;
end;
ttype2 = packed object(ttype1)
  b: integer;
end;
ttype3 = packed record
  a: integer;
end;

var
  tt1: ttype1;
  tt2: ttype2;

то ttype3(tt1) - нормально компилируется и работает, даже если в ttype1 добавить методы, а ttype3(tt2) - Error: Illegal type conversion: "ttype2" to "<record type>"

[zub]

>>Ещё вопросы, насколько допустимо приведение object к record и обратно и насколько object совместим с сишной struct.
Вообще так делать не стоит, но при желании... Без виртуальных методов должно работать один один, при появлении оных в запись нужно добавить PVMT:Pointer на соответствующем месте

>>ttype3(tt2) - Error: Illegal type conversion: "ttype2" to "<record type>"
чето я намудрил...
pttype3(@tt2)^ должно работать, но это некрасиво. чтоб избежать таких ситуаций нужно использовать методы, а не процедуры куда передаются объекты

[Vadim]

насколько object совместим с сишной struct.

Если рассуждать здраво ( ), то сишный struct - это набор разнотипных данных, а object - это набор данных и методов обработки этих самых данных. Так что судите сами насколько совместим struct и object.

Добавлено спустя 4 минуты 29 секунд:

Ещё вопросы, насколько допустимо приведение object к record

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

[Гость]

насколько object совместим с сишной struct.

Если рассуждать здраво ( ), то сишный struct - это набор разнотипных данных, а object - это набор данных и методов обработки этих самых данных. Так что судите сами насколько совместим struct и object.

Меня не интересуют методы, меня интересуют именно данные. Насколько это совместимо. В объекте привлекает возможность наследования, что дает в результате, возможность построения логически упорядоченной, взаимосвязанной и целостной системы простых данных, как это возможно, к примеру, в обероне или с использования классов, но без их громоздкого и ненужного, в данном случае, функционала. Очень бы хотелось иметь возможность наследования у обычной record, а синтаксический сахар в виде методов был бы совсем не лишним.

Ещё вопросы, насколько допустимо приведение object к record

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

Речь не о смысле или его отсутствии, просто ситуации бывают разные.
У нас есть распределенная система управления, построенная по модульному принципу, работающая в различном операционном окружении на различных архитектурах, в том числе еще на PDP-11. Конечно, постепенно мигрируем на современное железо, но в некоторых случаях это не целесообразно, да и не имеет смысла, т.к. имеющиеся платы на старых добрых советских шедеврах 1801ВМ2/1806BM2 легко обрабатывают то, с чем с трудом справляется современный пентиум
Так вот, небольшая часть софта, не особо критичного по надежности, написана на c/c++. Это процентов 8-10 кода. Чуть больше на паскале.
Остальная часть софта (в том числе о операционки) написана на собственном языке, напоминающего по идеям оберон, но русифицированный и сильно измененный как по синтаксису (есть нормальная объектная поддержка), так и по наличию библиотек, с использованием своего же кросскомпилятора, который поддерживает компиляцию для pdp-11, vax-11, dec alpha, arm, i386, но большая часть исходников сего чуда утеряны, а первоначального разработчика я не знаю.
Но система расширяется, меняется железо, развивается софт, приходится использовать другие языки и компиляторы, думаю перейти на FPC и теперь нужно это всё состыковать (я бы с удовольствием оставил старый компилятор, но он не поддерживает новые процессоры и нет большей части исходников для развития).
Так что вопрос о приведении типов совсем не праздный, а самый что ни на есть животрепещущий.

[Vadim]

Речь не о смысле или его отсутствии

Вы ошибаетесь... Отсутствие смысла сильно мешает писать программы. Для того, чтобы решить задачу тем или иным образом, надо знать как условие задачи, так и инструменты с помощью которых её можно решить. Вы знаете условия но не знаете инструменты, мы знаем один из инструментов (FPC), но не знаем условия. Получается разрыв единой цепочки. Чему ж Вы тогда удивляетесь, что ответы получаются для Вас маловразусмтельные?