dual model is bad idea? say that to advanced record creators! THAT was a bad idea, to make records with bonuses if we has objects already.
And your Void classes will be little more than unuseful coz direct descendants will be not compatible with TObject descendantsWhich is intended. Do you need a Tobject descendand?. Declare a TMyClass=class(TObject).
I think it's desirable some kind of lightweight class without all the bloat like a
TVoidClass and TObject should derive from the TVoidClass.
TObject is half bloated, half hacky and full oversized for nearly 99.9% of uses.
I think it's desirable some kind of lightweight class without all the bloat like a
TVoidClass and TObject should derive from the TVoidClass.
There is no desire to change or extend the object model. If you need something lightweight use object.
QuoteTObject is half bloated, half hacky and full oversized for nearly 99.9% of uses.
First: if smartlinking is enabled (default on Windows) any non virtual methods of TObject are removed.
Second: nothing there is hacky, it's simply a type that makes use of the low level information generated by the compiler, that's why it's a core type of the RTL.
Third: It's not oversized for 99.9% of uses, because the LCL makes use of nearly all the functionality provided by TObject to provide all the functionality we know and love and LCL usage is clearly more than 0.1%.
1.- Object is a stack type one, not heap. (can be heap, but without sugar sintax)1. So is C++ did you know that?
2.- Object is deprecated in delphi and only maintained in fpc, no further development
3.- Object doesn't accept all the syntax and has no sugar-syntax implemented.
IMHO advanced records aren't a bad idea. See https://forum.lazarus.freepascal.org/index.php/topic,46306.msg329970.html#msg329970
Such auto objects gives some advantages that C++ has by default.
1.- Object is a stack type one, not heap. (can be heap, but without sugar sintax)
2.- Object is deprecated in delphi and only maintained in fpc, no further development
3.- Object doesn't accept all the syntax and has no sugar-syntax implemented.Quote1. So is C++ did you know that?
2. There are reports at Embarcadero to deprecate deprected for objects
3. True, but still much of it
If you are reluctant to use objects you can always use class abstract.
On small, memory prssured, embedded applications I would go for either Object or fully procedural code.
If you are reluctant to use objects you can always use class abstract.And it will be marvellous if i can declare TMyAbstractClass = class (ReallyEmptyVoidClass) and then define it and it only occupies their vmts and tables with the minimal operational info. And less memory movement.. and better maintenance than procedural-only.
On small, memory pressured, embedded platforms I would go for either Object or fully procedural code.Well, in this scenario i go for only procedural (better say:structured) paradigm and not mix with OOP paradigm in Pascal because i couldn't rely on their future. If a void class or similar c++ construct (which should be obvious to put on top of any hierarchy like object) i would prefer oop if the memory pressure is not very very critical. This applies to C++ too.
But the main question is why is difficult or not viewed as neccesary a Void object which should be the academic root to start working and gives tools to do other things and not Lazarus-delphi ones?
Not too much gain...
On small, memory pressured, embedded platforms I would go for either Object or fully procedural code.
Meanwhile the DOS version uses .NET Core’s ability to produce self-contained executables along with some very significant tricks to pare down the size of the finished program from many megabytes to an eventual DOS-suitable 27k.https://hackaday.com/2020/02/09/c-the-language-for-all-platforms-now-including-windows-3-11-and-dos/
But the main question is why is difficult or not viewed as neccesary a Void object which should be the academic root to start working and gives tools to do other things and not Lazarus-delphi ones?
Simply because it's not necessary. If you need something lightweight you can use records or objects. There is simply no need to introduce yet another concept.
Not too much gain...
Even then the methods exist only once inside the binary. Yes, the virtual methods are referenced in each VMT, but each VMT only exists once per class type. There are much bigger size related problems than that in the RTL (e.g. that the whole managers for strings, memory, threads, etc. can't be smartlinked).
As I've recently realized, there isn't a strict necessity to use classes on the heap:On small, memory pressured, embedded platforms I would go for either Object or fully procedural code.
Let's face it, conventional wisdom has it that the entire concept of a heap is incompatible with resource-constrained systems. OK so you can deallocate locally in the reverse order to allocation... but at that point you might as well be putting stuff on the stack. Except of course that the stack has its own hazards if the platform can't increase its size on demand. Which is something that the majority of CS graduates find hard to stomach, which makes them fundamentally unsuited to embedded system work.
*snip*
As I've recently realized, there isn't a strict necessity to use classes on the heap:
https://forum.lazarus.freepascal.org/index.php/topic,54470.msg404786.html#msg404786
with the only trouble that the class InstanceSize is not well known at compile time to declare storage with the exact size.
Anyway, I can't understand exactly where is the problem with object :(
Zero Cost.Except bow and arrow notation to access the heap parts.... ->
Pascal is a low level with strong types and better aproach to avoid mistakes and gives (INMHO) better foundation than C. Then, for low level, it could do the job same or better than C or C++ (less error prone).
I think we are mixing syntax with power. A void class gives a power tool to the developer. Perhaps useful, perhaps useless, but gives the basic foundation. Tobject it's too big. And object it's not properly maintained (well the effords won't be here).
I think, for example (this could be as a general view) that if i would like to do a smart pointer (a low-middle level aproach) in C++ i can do it with oop paradigm or structured. In FPC i cannot do it because of the overbloat with classes. But i can, ironically, make my own memory manager, to, for example, redirect all heap calls to stack calls or my own internal memory.
Do the calculus:
how many bytes is the minimal size of a TObject?
{$mode delphi}
uses classes;
var x : tobject;
begin
x:=tobject.create;
writeln(x.instancesize);
end.
How many indirections even for a simple task like constructing it?. Then ask same for a void one (a similar c++ example).
But the main gain is not that.
The main gain is to eliminate dual mainteinance of object/tobject and the aperture of a powerful tool with full compatibility (really even more potent that the c++ counterpart, more mainteinable and similar or better speed).
Please. Figure how to implement it and as compiler dev you will see a lot of sinergies. Like the academical view find.
how many bytes is the minimal size of a TObject?The size of the empty class data (like TObject) is exactly the same as the data size of an empty classic object - it's just the size of a pointer to the VMT. How classes and objects would work without a VMT?
dual model is bad idea? say that to advanced record creators! THAT was a bad idea, to make records with bonuses if we has objects already. And your Void classes will be little more than unuseful coz direct descendants will be not compatible with TObject descendants
So TVoid would be a pointer (like any object) to the instance-mem. The instance-mem would have a pointer to the VMT, but the VMT would be 0 bytes.
Sure of course in theory that can be done conditionally. Except then you need some flag that distinguishes a VMT with RTTI from one without....
So TVoid would be a pointer (like any object) to the instance-mem. The instance-mem would have a pointer to the VMT, but the VMT would be 0 bytes.
Hypothetically: would a TVoid require the capability of virtual methods, or could that be added in its descendants, i.e. TObject et al.?