Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2007-05

Class Memory Table Size

4 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Andrew Haines

Hi,

In this page
http://www.freepascal.org/docs-html/prog/progsu139.html#x189-1950008.2.13 in the VMT +0 is the "Size of object type data" and the same number in the negative is stored at +4. How important is it that this number is not changed after the object is created? I want to store a number especially at +0. What is stored after that does not matter.

The reason for this is, I want to trick gtk into thinking that a TObject is really a GObject. This is where the TypeID for GType's are stored. I know this won't work for most GObject's, but I am only implementing this for a GInterface which is looked up by the TypeID, so that is all I need.

I've tested this and it is working. But what horrible things can happen?

Thanks,

Andrew Haines

Daniël Mantione
to Andrew Haines

Op Tue, 8 May 2007, schreef Andrew Haines:

Show quoted text 8 lines
Hi, In this page http://www.freepascal.org/docs-html/prog/progsu139.html#x189-1950008.2.13 in the VMT +0 is the "Size of object type data" and the same number in the negative is stored at +4. How important is it that this number is not changed after the object is created? I want to store a number especially at +0. What is stored after that does not matter.

These fields are used by several RTL routines that operate on classes, which will no longer function correctly. For details we need to search the source code.

Show quoted text 6 lines
The reason for this is, I want to trick gtk into thinking that a TObject is really a GObject. This is where the TypeID for GType's are stored. I know this won't work for most GObject's, but I am only implementing this for a GInterface which is looked up by the TypeID, so that is all I need. I've tested this and it is working. But what horrible things can happen?

I think it is much better to use objects for this rather than classes. A construction like this:

type   gobject=object
         gobject_typeid:...;
       end;
       gobject_child=object(gobject)
         constructor init;
         destructor done;virtual;
       end;

... will exactly to what you want: the gobject_typeid is at offset 0 while the size and vmt index are stored after that.

Daniël

Andrew Haines
to Daniël Mantione
Daniël Mantione wrote 25 lines
Op Tue, 8 May 2007, schreef Andrew Haines: > The reason for this is, I want to trick gtk into thinking that a TObject > is really a GObject. This is where the TypeID for GType's are stored. I > know this won't work for most GObject's, but I am only implementing this > for a GInterface which is looked up by the TypeID, so that is all I need. > > I've tested this and it is working. But what horrible things can happen? I think it is much better to use objects for this rather than classes. A construction like this: type gobject=object gobject_typeid:...; end; gobject_child=object(gobject) constructor init; destructor done;virtual; end; ... will exactly to what you want: the gobject_typeid is at offset 0 while the size and vmt index are stored after that. 
type
  TBaseObject=object
    FGObject: TGObject;
  end;
  TMyObject=object(TBaseObject)
    procedure MyProcedure; virtual; cdecl;
  end;

This is working perfectly. I am letting gtk allocate the object's memory, then in the instance_init func that gtk calls I am running .Init for the object and voila! I have a real object that I can pass to gtk and use in my program.

Thanks,

Andrew

Daniël Mantione
to Andrew Haines

Op Wed, 9 May 2007, schreef Andrew Haines:

Show quoted text 40 lines
Daniël Mantione wrote: > > Op Tue, 8 May 2007, schreef Andrew Haines: > >> The reason for this is, I want to trick gtk into thinking that a TObject >> is really a GObject. This is where the TypeID for GType's are stored. I >> know this won't work for most GObject's, but I am only implementing this >> for a GInterface which is looked up by the TypeID, so that is all I need. >> >> I've tested this and it is working. But what horrible things can happen? > > I think it is much better to use objects for this rather than classes. A > construction like this: > > type gobject=object > gobject_typeid:...; > end; > > gobject_child=object(gobject) > constructor init; > destructor done;virtual; > end; > > ... will exactly to what you want: the gobject_typeid is at offset > 0 while the size and vmt index are stored after that. > type TBaseObject=object FGObject: TGObject; end; TMyObject=object(TBaseObject) procedure MyProcedure; virtual; cdecl; end; This is working perfectly. I am letting gtk allocate the object's memory, then in the instance_init func that gtk calls I am running .Init for the object and voila! I have a real object that I can pass to gtk and use in my program.

I think this is an interresting way to talk to the gtk. I wonder how far can go interfacing directly without adding wrappers. I.e. most GTK function use a pointer to a GTK type as first parameter, which is binary compatible with a self pointer...

Daniël