Light LCL (LLCL) - Small Windows executable files v1.02

[Deepaak]

@ChrisF

Just awesome once again, very nice way to explain things. thank you bro.

[ChrisF]

@Derit

New bug fix (thanks for reporting it); expecting this time I've not missed another one, consecutive to my former fix.

GitHub repository updated.

[Deepaak]

What is the advantage of using Object over Classes.

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

1.   TStaticHandle = object
2.   // static object since we don't need to free any memory or read any property
3.   private
4.    .....
5.   end;    
6.  

[Thaddy]

The advantage of using object is - or has traditionally been - size, to some extend speed and it is more stack-friendly instead of favoring the heap. He could have used an advanced  record, though. It is the reason we use object by default with KOL, although class is a selectable  option in KOL At the expense of exponentially expanding size, that is. It is simply a matter of selecting the right structure for the right job.

[ChrisF]

@Deepaak

Well, it seems that Thaddy (thanks) has already answered to your question.

Just a few more words, more specific to the LLCL...

This choice has been made by the author of the LVCL, and I've seen no reason to modify it.

Furthermore, the LLCL is still compatible with Delphi7: and Delphi7 doesn't support "advanced records" (i.e. records with methods). And AFAIK, even with Free Pascal this feature is not activated by default: you must use "{$mode delphi}" or "{$modeswitch advancedrecords}" for it.

[Deepaak]

Thanks @ChrisF and @Thaddy

Actually my background is not from delphi so i am not much aware of usage of objects, as a brief survey yield me  below result from wiki.

Object Types

The Delphi compiler allows an alternative syntax to class types. You can declare object types using the syntax:

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

1. type
2.     objectTypeName = object (ancestorObjectType)
3.         memberList
4. end;
5.  

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 System.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.

http://docwiki.embarcadero.com/RADStudio/Seattle/en/Classes_and_Objects

As we all know that FPC is very near to Delphi 2010 now. Is it safe to use Object instead of Class. Because as mentioned by delphi wiki, object types are supported for backward compatibiltiy only, and is not recommended.

[ChrisF]

Yes,  I know the current situation for Delphi

However I think this is quite different for Free Pascal.  AFAIK, there isn't currently such a restriction (i.e. object type not recommended) for Free Pascal.

But I guess that only the Free Pascal developers could answer to the question. What is recommended for the future: object type or advanced record ?

PS. There have been some discussions about the subjects in the past. A few links:
http://forum.lazarus.freepascal.org/index.php/topic,8892.0.html
http://comments.gmane.org/gmane.comp.ide.lazarus.general/50315
http://free-pascal-general.1045716.n5.nabble.com/Advanced-Records-Why-not-available-by-default-td5143937.html

[Leledumbo]

What is recommended for the future: object type or advanced record ?

Define "future". If it's Delphi compatibility, certainly no. If it's something else, it could be yes. One thing for sure, FPC will not deprecate object type as Delphi does.

[ChrisF]

Define "future".[...]

I was generally speaking of the Free Pascal future ...

[taazz]

However I think this is quite different for Free Pascal.  AFAIK, there isn't currently such a restriction (i.e. object type not recommended) for Free Pascal.

Do advanced records support inheritance? If not then why would one choose advanced records for anything but raw data over objects?

[marcov]

But I guess that only the Free Pascal developers could answer to the question. What is recommended for the future: object type or advanced record ?

It happened to be discussed during last weeks hackathon too, and the opinions were varied. Of course we don't deprecate TP functionality like Borland did, but it is getting aged.

I'm more on the advanced record side, for the simple reason that it always has a guaranteed memory layout. (which is important for statically used types), while if you accidentally (or sb library from which you use objects) adds a virtual method to an object, that comes crashing down.

And I never  use inheritance in objects for non turbovision code.

Personally I'm starting to avoid projects that maintain D7 compatibility.

[Thaddy]

@Chrisf #34 Indeed advanced records were introduced in the D2005/6 series of Delphi. Their implementation  *on the Delphi side* is layout compatible with object and inheritance was in itially not supported. Object supports inheritance. Therefor you can use object as an alternative to advanced records. In this specific case it could have been an advanced record which has the same benefits as object has apart from inheritance.

@Deepaak #35 Well, there are some at the highest level on the technical side of the Delphi factory who actually like KOL (TRUE!)
You can take the deprecated status of object with a pinch of salt. Moreover, as I implied: it is a completely different paradigm from classes at the lower level. In some cases the use of object instead of a class can dramatically improve speed or size or both because of the stack over heap preference. Also, one tends to bold on everything and its mother onto the basic Tobject class which renders it, well, over engineered at the lowest level. Advanced records in part make up for that. If you are coding for speed, memory size and just have the occasional inheritance, you are better of with objects. As I stated: the right structure for the right job.

@ChrisF: objects and advanced records are not only semantically different, but also conceptional different, but they have the same use - but for inheritance. Classes are different again. I think we should keep them all . Most of the speed problems of modern object pascal classes as opposed to other languages can be explained away by favoring the heap over stack. We need such a structure.

[valdir.marcos]

The advantage of using object is - or has traditionally been - size, to some extend speed and it is more stack-friendly instead of favoring the heap. He could have used an advanced  record, though. It is the reason we use object by default with KOL, although class is a selectable  option in KOL At the expense of exponentially expanding size, that is. It is simply a matter of selecting the right structure for the right job.

What does KOL stand for?

[valdir.marcos]

... In some cases the use of object instead of a class can dramatically improve speed or size or both because of the stack over heap preference. Also, one tends to bold on everything and its mother onto the basic Tobject class which renders it, well, over engineered at the lowest level. Advanced records in part make up for that. If you are coding for speed, memory size and just have the occasional inheritance, you are better of with objects. As I stated: the right structure for the right job.

@ChrisF: objects and advanced records are not only semantically different, but also conceptional different, but they have the same use - but for inheritance. Classes are different again. I think we should keep them all . Most of the speed problems of modern object pascal classes as opposed to other languages can be explained away by favoring the heap over stack. We need such a structure.

Besides TObject and Advanced Records there aren't other possibilities to speed up Object Pascal Classes?

[Thaddy]

it is not Tobject. It is object plain and simple.
And yes there are ways to speed up individual applications using Tobject (means class of object) too.
But note I wrote *individual* not *general*.
E.g. I have experimented with a stack based memory manager for classes in the past but only for some specific applications with great results.
Delphi has an example of how to approach such a feat in grids.pas.

The speed gain is mostly when you need many many instances of a class that have a very very short life-time, like in real-time stock trades or probing. Some of that can be solved by a caching pattern on classes, but not all of it.