Class - when is it destroyed?

[janvb]

If we believe the author of aggpas (a vector library) it is substantial enough that he chose it over the classic classes. If you do take in to account that in a library like that you might have thousands of primitives (circles, lines,polylines and other shapes) it becomes even faster as the count goes up.

Actually it was the insides of some libraries in here with serious performance problems that made me ask. As a real-time C/C++ developer you become very aware of these things - in other languages they rightfully abstract away from these details. And as computers get faster with more memory developers care less and less - which is good since you are more productive on the functional side - but we need to get these details right in places where we need performance.

[taazz]

Actually it was the insides of some libraries in here with serious performance problems that made me ask.

Which libraries I wouldn't mind running a speed test on my laptop to see it my self.
To tell you the truth I wouldn't mind help write such application with various back ends.
If you are interested drop me a PM to set up a sourceforge project so we can play round.

As a real-time C/C++ developer you become very aware of these things - in other languages they rightfully abstract away from these details. And as computers get faster with more memory developers care less and less - which is good since you are more productive on the functional side - but we need to get these details right in places where we need performance.

well as a dos pascal programmer you become aware of those too but you byte the bullet and try not to care as technology evolves in ways you think are inexcusable. After all fighting against the current becomes tiresome very fast.

[janvb]

Which libraries I wouldn't mind running a speed test on my laptop to see it my self.
To tell you the truth I wouldn't mind help write such application with various back ends.
If you are interested drop me a PM to set up a sourceforge project so we can play round.
ble. After all fighting against the current becomes tiresome very fast.

I will set up a performance demonstration after I get back from holliday.

[Edson]

Frecuently I'm worried about of performance when using class, and I prefer to use Pascal objects. Probably beacuse I'm from the assembler school.

In some critical codes, I prefer to  use records, or objects instead of classes, if it is posible without sacrifice design and clarity.

But what I really, really would like is to have automatic constructors and destructors with objetcs.

[marcov]

The second issue is memory fragmentation over time. In a GUI that is no-care because you restart the application within a month - on a real-time backend system this will kneel down both Windows, Linux and Solaris and probably every known OS after 1-2 years in operation.

Memory allocation is easily avoided by avoiding allocation/deallocation cycles for large blocks (by simply keeping them around and recycling them, manually, or with pools).  Not all memory managers suffer from it in same manner anyway (e.g. fastmm in Delphi 2006+ and FPC's memmanager suffer much less from this than the old D6/D7 memory allocator). Static records are only used in exceptional cases (where you have millions of accesses/s).

I usually set up everything normally, and only optimize some of the important trajectories later (in my case, machine vision, typically e.g. blob detection buffers,  and the image buffers themselves)

When I started in the field, I was really scared too, and while such issues exists (where you need microoptimization and a bit of management to avoid memfragmentation), most problems are due to programming errors. If your code is clean and stable, if some odd ball thing happens or is limiting, it is easily found and fixed/optimized.

[janvb]

This is one of the weaker sides of FPC as a language. The syntax don't tell you if your using stack or heap, but you still need to manually destroy what you create on the heap  .

I which I could add syntax like

m : MyObject on heap;

to force an object to the heap and have it destroyed as we leave scope

m : MyObject on heap, persistent;

to create it on heap and avoid it from being destroyed.

m : MyClass on stack;

to force a class to the stack,

but well, santa never listens 

[marcov]

This is one of the weaker sides of FPC as a language. The syntax don't tell you if your using stack or heap

That's because the normal objects are always on the heap. Problem solved :-)

As for the persistent property (not really a good name for the property, "auto" would be more logical) Automatic memory management of objects (aka garbage collections) would totally change the language and its purpose. There have been threads about this in the past, if you are interested in the tradeoffs.

 

[janvb]

That's because the normal objects are always on the heap. Problem solved :-)

Class is on heap, Object is on stack.

[taazz]

That's because the normal objects are always on the heap. Problem solved :-)

Class is on heap, Object is on stack.

I have already said it once I'll repeat it for the last time classes are neither in heap nor stack, only objects are placed in heap or stack there are 2 types of object definition one is the class type which can create objects only on heap and the other is the old style objects which can be created both in heap and stack in order to create them in heap you simple define them as pointers of an object and use the new function to allocate memory.

 

[marcov]

That's because the normal objects are always on the heap. Problem solved :-)

Class is on heap, Object is on stack.

Stack objects are 15 year+ deprecated. Factoring it in as an requirement in
a redesign of the object system is not logical, since it would be incompatible with old code.

... which is the only reason it is still there.

[janvb]

Stack objects are 15 year+ deprecated. Factoring it in as an requirement in
a redesign of the object system is not logical, since it would be incompatible with old code.

... which is the only reason it is still there.

Actually I assumed that object and class only differed by stack or heap usage, but I notice other differences.

The challenge with heap only objects is that in real-time control systems you can't use dynamic memory inside a real-time loop. This is even regulated in standards. With stack object being deprecated FPC will not be very attractive for real time control systems. I like FPC, but I am not sure how to get around this issue.

[marcov]

Actually I assumed that object and class only differed by stack or heap usage, but I notice other differences.

The challenge with heap only objects is that in real-time control systems you can't use dynamic memory inside a real-time loop.

Then you can barely use OOP at all. Since an inherited object might use more space than the base object, you can't use any
form of polymorphism. 

If for some reason, you want to pretend that your procedures are inside records, use record declaration with methods in it.

This is even regulated in standards. With stack object being deprecated FPC will not be very attractive for real time control systems. I like FPC, but I am not sure how to get around this issue.

Afaik those guidelines were never really 100% required except for a few special (medical, military) cases (and varied from nation to nation). And even there they have been loosened a lot since the late eighties/early nineties. (including aircraft carriers using windows 2000). But in those cases, usually programming language to use and umpteen more things are strictly described, and you won't be using FPC/Delphi anyway :-)

[janvb]

Afaik those guidelines were never really 100% required except for a few special (medical, military) cases (and varied from nation to nation). And even there they have been loosened a lot since the late eighties/early nineties. (including aircraft carriers using windows 2000). But in those cases, usually programming language to use and umpteen more things are strictly described, and you won't be using FPC/Delphi anyway :-)

It is not as rare as you believe. IEC61508 (similar to MISRA on software) is civilian industry, automotive, robotics, automation, factory/plant equipment. The standard itself escalate with risk of lifes on failure, but it is an increasing awareness in the industry that software failure cost money as more and more use computers.

Is Delphi 7 different from FPC on this? Since I find that Delphi 7 is used in this context?

[marcov]

It is not as rare as you believe. IEC61508 (similar to MISRA on software) is civilian industry, automotive, robotics, automation, factory/plant equipment. The standard itself escalate with risk of lifes on failure, but it is an increasing awareness in the industry that software failure cost money as more and more use computers.

Only the parts that can cause physical or environmental harm. (e.g. trip systems when a door is opened, and kill switches for doors). Things that cause extensive damage to the machine are also usually protected, though that has reasons that are more economic in nature. And the wording is usually "that you need to be aware of risks, and asses  them". I don't really think they forbid certain approaches on the more normal levels.

But usually that is only a very small part of the total machine control, and often isolated in hardwired discrete components with a PLC especially designed and validated for security and safety in charge of them.  For many cases solutions are available off the shelf. Doing it this (uniform across a plant) way is usually also easier to modify and revalidate for the customer.

While we are mostly a vision company, occasionally we build custom machinery around the quality control, and most customers don't even want us to go there at all, but build their own safety system using modular, validated components.  If only because they want some control over it (wanting the whole conveyor line to stop if the  security mechanism of one machine trips, reset suppressible alarms from multiple locations etc).

But I assume if you make equipment in larger series without customization in this area, costs factors in, yes you will probably have to do it yourself. 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.

Is Delphi 7 different from FPC on this? Since I find that Delphi 7 is used in this context?

Yes, of course. FPC is more advanced!

(
It has the D2006 expansion to add methods to records, which make the old objects even more redundant. While  old objects are more powerful (inheritance and polymorphism),  that is nearly useless cases where  dynamic allocation is forbidden. (and even dangerous, if you e.g. rely on the object to match some predefined memory layout, one accidental "virtual" and under the hood a hidden field is added to TP objects)

That being said, one could just as well argue one doesn't need OOP at all, since the good parts are prohibited and just use  normal procedural programming. Our machine control is plain C, so without OOP.
)

[janvb]

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

The result above is with an interation of 10 million where a stack object perform at 0.13 sec while a heal object perform the same operation at 2.1 sec. I suspect that this is one of the reasons I find graphics in here a bit slow. My point is that heap objects have their usage, but so do stack objects. I would really like a way to use a "class" on stack to optimize some of the graphics.

The code is attached below.

program Project1;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Classes, SysUtils, CustApp
  { you can add units after this };

type

  { TMyApplication }

  TMyApplication = class(TCustomApplication)
  protected
    xx : Integer;
    procedure DoRun; override;
  public
    constructor Create(TheOwner: TComponent); override;
    destructor Destroy; override;
    procedure WriteHelp; virtual;
    procedure IterateObject;
    procedure IterateClass;
  end;

  MyObject = object
  public
    x : Integer;
  end;

  MyClass = class
  public
    x : Integer;
  end;

  { TMyApplication }

procedure TMyApplication.DoRun;
var
  ErrorMsg: String;
  x : Integer;
  h : integer;
  t1,t2,t3: TDateTime;
  tto,tts:TDateTime;
  str : string;
begin
  h:=10000000;
  t1:=Now;
  for x:=0 to h do
       IterateObject;
  t2:=Now;
  for x:=0 to h do
       IterateClass;
  t3:=Now;
  tto:= t2-t1;
  tts:= t3-t2;
  WriteLn('Stack Object Iteration:' + FormatDateTime('ss.zzz', tto));
  WriteLn('Heap Object Iteration :' + FormatDateTime('ss.zzz', tts));
 // Terminate;
end;

constructor TMyApplication.Create(TheOwner: TComponent);
begin
  inherited Create(TheOwner);
  StopOnException:=True;
end;

destructor TMyApplication.Destroy;
begin
  inherited Destroy;
end;

Procedure TMyApplication.IterateObject;
var
  x : MyObject;
begin
   x.x:=1;
   xx := xx+x.x;
end;

Procedure TMyApplication.IterateClass;
var
  x : MyClass;
begin
   x := MyClass.Create;
   x.x:=1;
   xx := xx+x.x;
   x.Free;
end;

procedure TMyApplication.WriteHelp;
begin
  { add your help code here }
  writeln('Usage: ',ExeName,' -h');
end;

var
  Application: TMyApplication;
begin
  Application:=TMyApplication.Create(nil);
  Application.Title:='My Application';
  Application.Run;
  Application.Free;
end.