[SOLVED] Asking for an example of an object cloning itself

[Gustavo 'Gus' Carreno]

Hey Y'All,

I always mess it up when using any type of non generics object list. My favourite is TFPObjectList from Contnrs cuz it has no notification events.
So, a thought came to mind: Wouldn't it be nice if when we ask for owned items, the list would clone the object and then we could do this:

Code: Pascal  [Select][+][-]

1. MyObjectVar:= TMyObjectClass.Create;
2. // Set some stuff on MyObjectVar's properties
3. MyObjectList.Add(MyObjectVar); // Store it away in a list that owns it's items
4. MyObjectVar.Free; // Free it so we don't have to worry about it

I'm kinda guessing that this would involve RTTI, and everyone tries to avoid it if they can. It bloats everything up down the line.

Then I thought: This is a great question to ask on the forums!! And here I am!!

• Would a self cloning Class be possible without RTTI? If so, please provide code example.
• If not, lets think with RTTI! Please provide code example.

Cheers,
Gus

[paule32]

you can inspect the SYSTEM.PAS Module ...
and you can discover a struct that holds VMT Fields that are used for RTTI - which are important Thing of FPC Runtime (Compiler) and the Runtime Library (RTL) itself.

The FPC Runtime and the RTL are essential Things in / within the FP Compiler and can not be simple replace.

You have to deal with a bunch of COMPILERPROC edure's you must have and this is not enough.
These COMPILERPROC's must be occur in a voodoo Order in Modules and Positions.

[PascalDragon]

Then I thought: This is a great question to ask on the forums!! And here I am!!

• Would a self cloning Class be possible without RTTI? If so, please provide code example.
• If not, lets think with RTTI! Please provide code example.

It's not even (safely) possible with RTTI, because some internal state might not be exposed through a published property.

The way to do this is to have a base class that provides some kind of virtual Assign method that does the dirty work of copying the object instance. This way is also used in the RTL with TPersistent.

you can inspect the SYSTEM.PAS Module ...
and you can discover a struct that holds VMT Fields that are used for RTTI - which are important Thing of FPC Runtime (Compiler) and the Runtime Library (RTL) itself.

The FPC Runtime and the RTL are essential Things in / within the FP Compiler and can not be simple replace.

You have to deal with a bunch of COMPILERPROC edure's you must have and this is not enough.
These COMPILERPROC's must be occur in a voodoo Order in Modules and Positions.

All that is not relevant for the topic at hand. You don't need to shoot with cannons at sparrows for cloning objects.

[Gustavo 'Gus' Carreno]

Hey paule32,

you can inspect the SYSTEM.PAS Module ...
and you can discover a struct that holds VMT Fields that are used for RTTI - which are important Thing of FPC Runtime (Compiler) and the Runtime Library (RTL) itself.

The FPC Runtime and the RTL are essential Things in / within the FP Compiler and can not be simple replace.

You have to deal with a bunch of COMPILERPROC edure's you must have and this is not enough.
These COMPILERPROC's must be occur in a voodoo Order in Modules and Positions.

Don't get me wrong, I do appreciate your insights, quite a lot...

But... Where's the code ?!?!

Cheers,
Gus

[Gustavo 'Gus' Carreno]

Hey PascalDragon,

Missed your, always very welcomed, insights!! Hope you're doing well !!

Then I thought: This is a great question to ask on the forums!! And here I am!!

• Would a self cloning Class be possible without RTTI? If so, please provide code example.
• If not, lets think with RTTI! Please provide code example.

It's not even (safely) possible with RTTI, because some internal state might not be exposed through a published property.

The way to do this is to have a base class that provides some kind of virtual Assign method that does the dirty work of copying the object instance. This way is also used in the RTL with TPersistent.

Okidokes !! So, for code examples have a look at any Class that sponsors an Assign method, starting with TPersistent and it's ancestor. Gotcha !!!

As per usual, many thanks for dropping your gems, you're the ultimate mother goose ( and I say this with the utmost love )

All that is not relevant for the topic at hand. You don't need to shoot with cannons at sparrows for cloning objects.

I'm gonna be VERY rude and laugh my arse off at this

Cheers,
Gus

[paule32]

@Gus:

I wrote in the Context, that you need a own SYSTEM.PAS Module like me.
With Help of fibodev I have wrote a own SYSTEM.PAS and needed COMPILERPROC edure's - not all, but many ...

So I was thinking, if you wan't to have your own RTTI, you can do this with own RECORD s and own RECORD Fields.

But since the Bootstrap for this contains FPC Original Code, you have a payload of Meta Information's till you broke it down to your need.

But this implicit that you write your own Pascal Compiler...
And this can be a very high risk, and time waste ...

[marcov]

The pre RTTI way:

https://stackoverflow.com/questions/4041760/correct-way-to-duplicate-delphi-object

[Thaddy]

I would write a class function for that.

[Khrys]

I think a special-purpose method (the approach taken by  TPersistent) might be the only solid option.

Sure, you could do a simple bitwise copy:

Code: Pascal  [Select][+][-]

1. function TObject.Clone(): TObject;
2. begin
3.   TObject(Result) := NewInstance();
4.   Move(Pointer(Self)^, Pointer(Result)^, InstanceSize());
5. end;

But this will mess up managed types (strings, arrays etc. will cause use-after-free due to the reference count being too low) and, in the case of references (pointers, class instances) only copies the pointer value (no deep copy).

Even if you handled managed types correctly you'd still have to decide whether to deep-copy references, which might still be somewhat doable with classes (but requiring prior knowledge of deep vs. shallow types) but is completely unfeasible for opaque pointers.