Отличие type T = Object от type T = Class?

[Warn]

В чем заключается отличие type T = Object от type T = Class?

[Пепел Феникса]

As an alternative to class types, you can declare object types using the syntax

type objectTypeName = object (ancestorObjectType)

memberList
end;

where objectTypeName is any valid identifier, (ancestorObjectType) is optional, and memberList declares fields, methods, and properties. If (ancestorObjectType) is omitted, then the new type has no ancestor. Object types cannot have published members.
Since object types do not descend from TObject, they provide no built-in constructors, destructors, or other methods. You can create instances of an object type using the New procedure and destroy them with the Dispose procedure, or you can simply declare variables of an object type, just as you would with records.

Object types are supported for backward compatibility only. Their use is not recommended.

в справке же все есть.

[Warn]

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

теперь понятно что это некая альтернатива. только не понятно object поддерживает наследование как class?
object - не поддерживает конструкторы и деструкторы, нужно вызывать new и dispose, но наверное объект описанный как object работает несколько быстрее, поскольку вся эта гирлянда методов с TОbject не тянется как у classa.

[Пепел Феникса]

теперь понятно что это некая альтернатива.

object это корень.

type TObject=object

Это совместимость с паскалем, в нем было именно так.

только не понятно object поддерживает наследование как class?

Поддерживает.

object - не поддерживает конструкторы и деструкторы,

Поддерживает(вроде), синтаксис работы тот же.
Просто в нем нет ничего изначально, ни деструктора, ни конструктора.

Так же можно с ними работать как с записями(так же через New/Dispose создавать/удалять)

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

у меня от Д6.

но наверное объект описанный как object работает несколько быстрее, поскольку вся эта гирлянда методов с TОbject не тянется как у classa.

Там разница лишь с созданием и удалением. чуток дольше(пара нс)
Тем не менее TObject гибче.

и еще:

Object types are supported for backward compatibility only. Their use is not recommended.

[GunSmoker]

Справку можно всегда увидеть здесь. В частности: classes and objects.

Ошибка по F1 - смотря какая ошибка. Возможно, справка просто не установлена.

object - это устаревшая конструкция, наследуемая Delphi из Borland Pascal-я. Грубо говоря, это записи с методами и наследованием. Весьма ограничены. Кроме того, поскольку эта конструкция оставлена в языке только по соображениям обратной совместимости, то её особо не тестируют и там полно багов. Лучше держаться от них подальше.

Основная разница между class и object (помимо более широких возможностей первого): class - это указатель (размещается в куче), object - это запись (размещается на стеке).

наверное объект описанный как object работает несколько быстрее, поскольку вся эта гирлянда методов с TОbject не тянется как у classa

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

[Warn]

Там разница лишь с созданием и удалением. чуток дольше(пара нс)

я попытался написать тест, чтобы проверить насколько и очевидна ли разница в доступе к полям и функциям класса и объекта.

вот что из этого получилось, и надо заметить что итераций у объекта больше в среднем в 2 раза.
inline - директива несколько помогает выправить ситуацию, но тем не менее перевес по скорости доступа к членам ... на стороне объекта.

program Project1;

{$APPTYPE CONSOLE}

uses
  SysUtils,
  Windows;

type CBox=class
public
     _x,_y,_z:Integer;
     constructor Create();overload;
     constructor Create(x,y,z:Integer);overload;

     function GetVolume():Integer;


end;

constructor CBox.Create();
begin
     self.Create(0,0,0);
end;
constructor CBox.Create(x,y,z:Integer);
begin
   _x:=x;
   _y:=y;
   _z:=z;

end;

function CBox.GetVolume():Integer;
begin
     result :=_x*_y*_z;
end;


type OBox=object
public
     _x,_y,_z:Integer;
     constructor Create();overload;
     constructor Create(x,y,z:Integer);overload;

     function GetVolume():Integer;
end;


constructor OBox.Create();
begin
     self.Create(0,0,0);
end;
constructor OBox.Create(x,y,z:Integer);
begin
   _x:=x;
   _y:=y;
   _z:=z;
end;

function OBox.GetVolume():Integer;
begin
     result :=_x*_y*_z;
end;


var
b1:CBox;
b2:OBox;
t:Integer;
i:Cardinal;
c:Cardinal=0;
begin

// Тест скорости доступа к полям и ф-ии класса
t:=GetTickCount()+2000;
b1:=CBox.Create();

while (t>=GetTickCount()) do begin
      b1._x:=100;
      b1._y:=50;
      b1._z:=2;

      for i := 0 to 1000 do
      begin
        b1.GetVolume();
      end;

      inc(c);
end;
b1.Free;
write('Class interations:');
writeln(c);



// Тест скорости доступа к полям и ф-ии объекта
t:=GetTickCount()+2000;
b2.Create();

while (t>=GetTickCount()) do begin
      b2._x:=100;
      b2._y:=50;
      b2._z:=2;
      for i := 0 to 1000 do
      begin
        b2.GetVolume();
      end;
      inc(c);
end;
write('Object interations:');
writeln(c);


readln;
end.

[GunSmoker]

Наивный :-D

Кто ж так делает.

Эти два куска кода генерируют почти идентичный машинный код:

b1._x:=100;
005107DA C7400464000000 mov [eax+$04],$00000064
b1._y:=50;
005107E1 C7400832000000 mov [eax+$08],$00000032
b1._z:=2;
005107E8 C7400C02000000 mov [eax+$0c],$00000002
b1.GetVolume();
005107EF E814FFFFFF call CBox.GetVolume

b2._x:=100;
00510802 C745F464000000 mov [ebp-$0c],$00000064
b2._y:=50;
00510809 C745F832000000 mov [ebp-$08],$00000032
b2._z:=2;
00510810 C745FC02000000 mov [ebp-$04],$00000002
b2.GetVolume();
00510817 8D45F4 lea eax,[ebp-$0c]
0051081A E885FFFFFF call OBox.GetVolume

Как видим, код на object оказался даже больше на 1 инструкцию.

А твоя разница в результатах объясняется тем, что у тебя погрешность изменения больше его точности.

1. Вызов GetTickCount стоит дороже установки свойств и вызова GetVolume.
2. Начало одного цикла может попасть на нечётную границу, а начало второго - на чётную. Вот и получится, что второй цикл будет впереди планеты всей. Но не потому, что его тело быстрее, а потому что само условие цикла быстрее выполняется.

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

"Преждевременная оптимизация - корень всех бед"

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

А та фигня, которой ты занимаешься, съест у тебя месяцы работы и даст прирост в 1 миллисекунду в час.

[Warn]

Наивный :-D

я бы сказал пытливый.

Кто ж так делает.

а как делают?

1. Вызов GetTickCount стоит дороже установки свойств и вызова GetVolume.

Согласен(ф-я win ядра ~ тормоза), но как мне кажется цена для обоих циклов одинаковая поэтому не в счет.

2. Начало одного цикла может попасть на нечётную границу, а начало второго - на чётную. Вот и получится, что второй цикл будет впереди планеты всей. Но не потому, что его тело быстрее, а потому что само условие цикла быстрее выполняется.

что за границы? есть желание просветить?

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

Ага.

Машинная оптимизация - дело сложное и неоднозначное.

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

Но самое главное правило тут:
"Преждевременная оптимизация - корень всех бед"

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

однако, все это я зря и все равно придется пользоваться "тормознымигибкимиклассами" как-нибудь переживу))

[GunSmoker]

http://www.ozon.ru/context/detail/id/1418882/
http://www.insidepro.com/rus/doc.shtml
http://wasm.ru/