From the Delphi (7) help and in the borland newgroups I read that the old TP style object type is considered to disappear, and actually only kept for code compatibility.

I see here that some developers still use the type object because of some advantages against the Class type (static allocation).

Can someone explain better these advantages?

My other question is:
Will Free Pascal still support the type object in the future or it is considered to disappear in the same way as it is expected in Delphi?

tia

The advantage is mainly that you can have objects on the stack.

My other question is: Will Free Pascal still support the type object in the future or it is considered to disappear in the same way as it is expected in Delphi?

It will not disappear, but all new development is done using classes: the old objects will not evolve.

Michael.

My other question is: Will Free Pascal still support the type object in the future or it is considered to disappear in the same way as it is expected in Delphi?

It won't disappear in FPC, even the compiler itself uses it at certain places.

Michael Van Canneyt ha scritto:

sorry, but don't understand exactly what this means exactly.

I understand that if I write a procedure of this kind:

procedure processmyobject(myobject: tmyobject);
procedure processmyobject(myclass: tmyclass);

I have myobject on the stack, instead myclass is passed by reference, but don't see the advantage...

Op Tue, 5 Feb 2008, schreef Tiziano De Togni:

Stack allocation is much faster than heap allocation, and automatic. Take a look at the matrix unit; you can return an object from a function without worrying about memory leaks, so they are very usefull in function results and operator overloading.

Further, objects allow you control the binary layout (the binary layout is just like a record), which means you can fit existing data structures (like those used in files) with methods. Some time ago we had a discussion about this list about mapping the GTK Gobject model to Pascal objects, succesfull experiments were done.

Daniël

The main difference is here:

-- 8< --
procedure Uses_Objects;
var
   My_Object : tMyObject;
   My_Class  : tMyClass;
begin
   My_Object.Init;
   My_Class := tMyClass.Create;
end {Uses_Objects};
-- 8< --

The memory allocation for the class can fail due to resource exhaustion and also is infinitely slower than the allocation for the object, which is there as soon as the procedure has been entered. On assembly level, it is only a different constant that the stack pointer is moved to make space for the local variables.

Referencing an instance being on the stack may also be a bit faster than referencing an instance being on the heap, because there's one level of dereference less, and it may be even more cache-friendly, because the stack is more likely to be in the cache already than a (newly) allocated memory block.

Meaning: Memory space and execution speed is more or less known beforehand and potential memory fragmentation problems are avoided.

Oh, and one thing more: No access violations when referencing an invalid (not yet initialized) instance. ;)

Vinzent.

Daniël Mantione wrote

[..]

In a external c library, i have a structure like

TMyType = record
  x: Integer;
  y: Integer;
end;
PMyType = ^TMyType;

and a function that expects a pointer to that record

function DoIt(MyVar: PMyType);

can i safely use the below object instead of the record and pass directly to the c function?

TMyObj = object
  x: Integer;
  y: Integer;
  Method1;
  Method2;
end;
PMyObj = ^TMyObj;

Moreover, whats the difference between objects and records with methods (the new Delphi feature)?

Luiz

Op Tue, 5 Feb 2008, schreef Luiz Americo Pereira Camara:

Yes, objects (by specification) are defined to have the same binary layout as records.

Moreover, whats the difference between objects and records with methods (the new Delphi feature)?

Objects can have virtual methods, constructors, destructors. The new Delphi feature cannot.

Daniël

The records-with-methods feature originates from .NET, but some cases were made that they were also added to restrict the search for methods for duck-type style other new delphi features like for..in, and similar future expansion. Probably when these features are more closely regarded, additional reasons/behaviour will pop up.

A very rough summary of the msgs and (IRC-)discussions about the newer delphi features can be found here:

http://www.stack.nl/~marcov/delphilater.txt

however with virtuals or constructors/destructors, the memory layout is not 100% the same as a record.

Marc

Another difference, the memory of a class is zeroed on creation. This means that all membervars have the value of 0/nil, where for an object only automated member types are initialized.

Marc

Op Tue, 5 Feb 2008, schreef Marc Weustink:

A constructor doesn't add a vmtlink. A virtual method does, and a destructor too because they are virtual. It is never a problem in practise, because you can declare the virtual method in a descendent, i.e.:

type  Tbinary_compatible_obj=object
         a,b,c,d,e,f:byte;
         constructor init;
       end;
       Tbinary_compatible_obj_with_vmt=object(Tbinary_compatible_record)
         constructur init;
         procedure virtualmethod;virtual;
         desctructor done;virtual;
       end;

In the above example, you can perfectly pass a
Tbinary_compatible_obj_with_vmt instance to any C library expecting a Tbinary_compatible_obj, because the vmtlink is located after the fields and therefore does not interfere with the binary structure.

Daniël

it might be a compiler bug, but when I tried to zeromem a object having a constructor it resulted in an IE. Without a constructor not. That way I came to a conlusion that an object+constructor is not 100% the same as a simple record.

Marc