Class - when is it destroyed?

[mse]

I would really like a way to use a "class" on stack to optimize some of the graphics.

The new programming language MSElang will have such a construct. There it is planned to unify records, objects and classes into a single concept.

[marcov]

I have made a test application just to document the difference in speed between stack- and heap- objects. This test was 10 million iterations to avoid inaccuracy from TDateTime, but tests on lower interations will show the same difference.

The question is how OOP such object use is, and what the practical worth of such example is. Otherwise it is just microbench-marking.

IOW what do you do with such object that you can't do with a record? Or even just a variable and some functions?

[taazz]

IOW what do you do with such object that you can't do with a record?

inheritance, extensibility overall. if the extended record type supported inheritance and virtual methods the old object types wouldn't be used.

Or even just a variable and some functions?

Encapsulation and extensibility. You could use a unit as component but there is nothing to support the virtual/dynamic attribute of a method in such a case and you will have problems supporting extensibility features.

[Edson]

I have made a test application just to document the difference in speed between stack- and heap- objects. This test was 10 million iterations to avoid inaccuracy from TDateTime, but tests on lower interations will show the same difference.
 Stack Object Iteration:00.133
 Heap Object Iteration :02.115

  It's a notorious difference. I'am scared now of using class. Thank's for to compare.

It's true, in many cases we are not worried about lost some microseconds (and to type some extra lines of code), but it would be wonderful if we had a way to declare a class for to be used on stack. IMHO it's a big lack of FPC.

[Edson]

[/code]

The new programming language MSElang will have such a construct. There it is planned to unify records, objects and classes into a single concept.

IMHO it's the best.

In fact, when I was designing an object oriented language, I defined two types of declaration for variables:

Code: [Select]

VAR    //created on stack
  n : integer;       //common integer variable   
  c: class ... end;  //created on stack

REF    //for to create on heap
  n: integer;  //like pointer to integer
  c: class ... end;  //like the common FPC class



[marcov]

IOW what do you do with such object that you can't do with a record?

inheritance, extensibility overall.

Only moderately useful since you still have to declare the derived object.

if the extended record type supported inheritance and virtual methods the old object types wouldn't be used.

As said to really make use virtual methods (polymorphism) requires dynamic instantiation.

Or even just a variable and some functions?

Encapsulation and extensibility. You could use a unit as component but there is nothing to support the virtual/dynamic attribute of a method in such a case and you will have problems supporting extensibility features.
[/quote]

You can't of course instantiate anything dynamical inside the object since that defeats the purpose. And you have to declare the final object. (since you can't declare a base object as local var and assign a derivative to it, that only works for the pointer to object)

So IMHO what's left of those properties are mere tokens at best.

[janvb]

The new programming language MSElang will have such a construct. There it is planned to unify records, objects and classes into a single concept.

I fail to find any specification for this?

[janvb]

If you have more info about the exact details in that directive, I'd be happy to hear/discuss them.  It is an interesting twist to the discussion, even IMHO they are no reason to glorify old TP objects.

I will see what I can find, but that standard is a pain... The software part start with simple things like headers, readability of code, pointers, dynamic memory and somewhere on the way it set requirements to how you organize everything from A-Z in your company by demaning that you work in according with CMM or similar. Much of the stuff is common sence, other things are ... well I don't have to agree with everything ....

[janvb]

  It's a notorious difference. I'am scared now of using class. Thank's for to compare.

Actually you seldom notice this. But, lazarus libraries are noticable slow on graphics and I suspect that this is one factor. There are ways around this - memory pools is a common trick. But, I am not sure if I can do this in FPC by overloading the memory allocation like I can in C++? I would like to see if I could do a few tricks to speed graphics up.

[Leledumbo]

[But, lazarus libraries are noticable slow on graphics and I suspect that this is one factor.

Nope, portability is. fcl-image libraries are written for maximum portability and the drawback is the speed.

But, I am not sure if I can do this in FPC by overloading the memory allocation like I can in C++?

http://www.freepascal.org/docs-html/prog/progsu176.html

[mse]

The new programming language MSElang will have such a construct. There it is planned to unify records, objects and classes into a single concept.

I fail to find any specification for this?

Not ready yet. Currently I am implementing the compiler framework in order to learn about the internal needs and possibilities. Feel free to write your thoughts and recommendations.
BTW, the MSElang compiler does not use many classes internally because I also found them too slow for many tasks. :-)

[marcov]

Actually you seldom notice this. But, lazarus libraries are noticable slow on graphics and I suspect that this is one factor.

Sadly, that is the only part that actually uses objects. (see graphtype). Afaik nothing is an class in Lazarus that is otherwise in Delphi, so if there
are huge differences, I don't think it is that simple.

There are ways around this - memory pools is a common trick. But, I am not sure if I can do this in FPC by overloading the memory allocation like I can in C++?

No you can't that way, you can install a custom memory manager that pools that allocation size, or use your own factories. The required filling with zeroes of new classes is also in the way.

It is also possible to mass instantiate and destroy instances (iirc fcl-xml's dom unit used to, but it could be that it is removed) by allocating a large block, zeroing it, dividing it up into class.instancesize, setting the vmt and then calling the constructor on it.

In any way it is a good thing to understand how the delphi class construction works (including mem safety in case of exceptions in construction), this because there are hooks you can (ab)use.

[marcov]

Nope, portability is. fcl-image libraries are written for maximum portability and the drawback is the speed.

I thought fcl-image was only used for streaming images? The drawing itself is Lazarus tlazintfimage/rawimage ?

[Leledumbo]

Nope, portability is. fcl-image libraries are written for maximum portability and the drawback is the speed.

I thought fcl-image was only used for streaming images? The drawing itself is Lazarus tlazintfimage/rawimage ?

I'm not sure whether the OP has problem with the calculation or rendering actually.

[janvb]

Feel free to write your thoughts and recommendations.
BTW, the MSElang compiler does not use many classes internally because I also found them too slow for many tasks. :-)

That would be a long thread since my own usage for FPC is mainly as a tool to create a new, experimental programming language that is far away from anything you know