Recent

Author Topic: Interfaces/Polymorphism  (Read 6026 times)

syntonica

  • Full Member
  • ***
  • Posts: 120
Interfaces/Polymorphism
« on: December 05, 2019, 02:28:18 pm »
I'm just beginning to learn Pascal (again...) and the OO part is confusing me!

What I want is an interface (as in Java) or an abstract class (as in C++) where I have several classes implementing them.

Type
ParentInterface = Interface...
....

ChildClass1 = Class...
...

ChildClass2 = Class...
...

Now, what I need is a pointer that's declared as Type ParentInterface, but can hold an instance of either ChildClass1 or ChildClass2. Is this how Pascal works? If not, do I go for a virtual class instead? I've tried reading the docs, but they're still rather opaque to me at this point.

Sorry for the brevity of my code example, but I'm only as far as "Hello, World" at this point, but I learn best by taking on a large project and working it out step by step. My goal is to ultimately maybe use Pascal instead of C++ for audio DSP development.



Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
Re: Interfaces/Polymorphism
« Reply #1 on: December 05, 2019, 03:09:00 pm »
Does this help?
Code: Pascal  [Select][+][-]
  1. {$mode objfpc}{$R+}
  2. type
  3.  THello = class
  4.  public
  5.    Function WhoAmI:string;virtual;
  6.  end;
  7.  
  8.  TWorld = class(THello)
  9.  public
  10.    Function WhoAmI:string;override;
  11.  end;
  12.  
  13.  Function THello.WhoAmI:string;
  14.  begin
  15.    write('Hello');
  16.  end;
  17.  
  18.  Function TWorld.WhoAmI:string;
  19.  begin
  20.    inherited;
  21.    write(', World');
  22.  end;
  23.  
  24. var
  25.  a:THello;
  26.  b:TWorld;
  27. begin
  28.  a:=THello.Create;
  29.  writeln(a.WhoAmI);
  30.  a.free;
  31.  b:=TWorld.Create;
  32.  writeln(b.WhoAmI);
  33.  b.free;
  34. end.
Specialize a type, not a var.

devEric69

  • Hero Member
  • *****
  • Posts: 648
Re: Interfaces/Polymorphism
« Reply #2 on: December 05, 2019, 03:19:18 pm »
What is important to understand, is that there is no garbage collector in Pascal (in Pascal, we destroy what we've created). So, the use of abstraction is more "natural" than the use of interfaces in Pascal.

You can have a look at this discussion, about using the interfaces in a Pascal context: https://forum.lazarus.freepascal.org/index.php/topic,46181.msg328478.html#msg328478 .

use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

syntonica

  • Full Member
  • ***
  • Posts: 120
Re: Interfaces/Polymorphism
« Reply #3 on: December 05, 2019, 04:04:17 pm »
Does this help?

Not quite, but thank you very much for the prototype!

Code: Pascal  [Select][+][-]
  1. {$mode objfpc}{$R+}
  2. type
  3.  THello = class
  4.  public
  5.    Function WhoAmI:string;virtual;
  6.  end;
  7.  
  8.  TWorld = class(THello)
  9.  public
  10.    Function WhoAmI:string;override;
  11.  end;
  12.  
  13.  Function THello.WhoAmI:string;
  14.  begin
  15.    write('Hello');
  16.  end;
  17.  
  18.  Function TWorld.WhoAmI:string;
  19.  begin
  20.    { inherited; }
  21.    write(', World');
  22.  end;
  23.  
  24. var
  25.  a:THello;
  26.  { b:TWorld; }
  27. begin
  28.  a:=THello.Create;
  29.  writeln(a.WhoAmI);
  30.  a.free;
  31.  
  32.  a:=TWorld.Create;  { <-this was my question here }
  33.  writeln(a.WhoAmI);
  34.  a.free;
  35.  
  36. end.
  37.  
Output:
"Hello
, World"
This worked as I hoped! C++-style FTW!  :D

My first project will be porting over my VST plugin from C++ for both Mac and Windows and there are a few changes I want to make at the very core that depend on polymorphism.  And I have to say, the ability to cross-compile might mean I only have to do final testing on the PC, no more programming!  Now, to see if I can get over Pascal's wordiness...

Last question to whomever is reading this: Is the a coding style manual or list of things you really should/shouldn't do?  I notice T's for types and I's for interfaces, etc., as well as different casing.

(Edit: fixed my bad copypasta.)
« Last Edit: December 05, 2019, 05:35:22 pm by syntonica »

syntonica

  • Full Member
  • ***
  • Posts: 120
Re: Interfaces/Polymorphism
« Reply #4 on: December 05, 2019, 04:08:36 pm »
What is important to understand, is that there is no garbage collector in Pascal (in Pascal, we destroy what we've created). So, the use of abstraction is more "natural" than the use of interfaces in Pascal.

You can have a look at this discussion, about using the interfaces in a Pascal context: https://forum.lazarus.freepascal.org/index.php/topic,46181.msg328478.html#msg328478 .

Thanks for the reply, but I'm really unsure why GC is relevant here. In C++, I new/delete and in Pascal, it looks like it'll be Create/Free.

kupferstecher

  • Hero Member
  • *****
  • Posts: 583
Re: Interfaces/Polymorphism
« Reply #5 on: December 05, 2019, 04:54:12 pm »
Code: Pascal  [Select][+][-]
  1. var
  2.  a:THello;
  3.  { b:TWorld; }
  4. begin
  5.  a:=THello.Create;
  6.  writeln(a.WhoAmI);
  7.  a.free;
  8.  
  9.  a:=TWorld.Create;  { <-this was my question here }
  10.  writeln(b.WhoAmI);
  11.  a.free;
  12.  
  13.  
It's should be mentioned, that the variable "a" is a reference to the instance only. So the below is legit code.

Code: Pascal  [Select][+][-]
  1. a:=THello.Create;
  2. b:= a;
  3. b.WhoAmI;
  4. b.free;
  5.  

mtournay

  • Jr. Member
  • **
  • Posts: 63
Re: Interfaces/Polymorphism
« Reply #6 on: December 05, 2019, 05:17:51 pm »
laz 2.06 32b - fpc 3.04 32b - win10 64b

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11382
  • FPC developer.
Re: Interfaces/Polymorphism
« Reply #7 on: December 05, 2019, 08:26:53 pm »
Thanks for the reply, but I'm really unsure why GC is relevant here. In C++, I new/delete and in Pascal, it looks like it'll be Create/Free.

Probably because the most used form of interfaces is reference counted. ("smart pointer").

syntonica

  • Full Member
  • ***
  • Posts: 120
Re: Interfaces/Polymorphism
« Reply #8 on: December 05, 2019, 10:24:53 pm »
Thanks for the reply, but I'm really unsure why GC is relevant here. In C++, I new/delete and in Pascal, it looks like it'll be Create/Free.

Probably because the most used form of interfaces is reference counted. ("smart pointer").

Oh! Okay! I was hoping I wasn't missing anything and it looks like I was, sort of. I'll have to watch out for that since I prefer malloc/free over RC.

I've decided how I'm going to proceed here and step one is to port over my graphics/UI engine written in GDI/Cocoa since:
1) I can't find any library that's similar, and
2) If this doesn't scare me away from Pascal, nothing will!
If it's a success, I will definitely share the unit and it will be my contribution to putting another stake in the heart of Carbon. If it had been written in anything other than Pascal, wouldn't we all be Cocoaized by now?


Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
Re: Interfaces/Polymorphism
« Reply #9 on: December 06, 2019, 04:04:09 am »
My first project will be porting over my VST plugin from C++ for both Mac and Windows and there are a few changes I want to make at the very core that depend on polymorphism.  And I have to say, the ability to cross-compile might mean I only
I actually did quite a lot of VST programming in Pascal (the first Pascal VST host was written by me and subs. improved by TobyBear and Christian, I also translated FreeVerb3 by Yezar to Pascal and quite a bit more original ones) so Yes, VST plugins and hosts are perfectly feasible. Christian wrote a very nice framework for it, based on my and subs. TobyBear's work. Also note some of the people from FL studio independently did the same thing: Fruity loops was basically written in Delphi and some of the original programmers are forum members. As is Christian.

So for sure, VST questions can be answered here as long as they are Pascal related.
« Last Edit: December 06, 2019, 04:07:20 am by Thaddy »
Specialize a type, not a var.

syntonica

  • Full Member
  • ***
  • Posts: 120
Re: Interfaces/Polymorphism
« Reply #10 on: December 06, 2019, 06:17:10 am »
by TobyBear

So for sure, VST questions can be answered here as long as they are Pascal related.

I've got his VST 2.3 SDK Pascal translation lying around here somewhere. I'll have to update it to 2.4, but most of the heavy lifting is done.

I've been trying little tests comparing bespoke functions that I'll know I'll be needing in a head-to-head C vs. Pascal battle. C was winning by a significant amount until I discovered the -CSSE3 switch, which put Pascal into the lead! (against GCC -Ofast.)

One thing I've been surprised by is that, so far, orthography aside, Pascal is far more elegant and expressive than C. C libraries seem to have been designed by sadomasochists (which I thought was the realm of C++ designers.) I'm constantly hammering at a nail with screwdrivers, pliers and saws, where Pascal seems to always hands me just the right size hammer for the job.

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
Re: Interfaces/Polymorphism
« Reply #11 on: December 06, 2019, 09:02:59 am »
I've got his VST 2.3 SDK Pascal translation lying around here somewhere. I'll have to update it to 2.4, but most of the heavy lifting is done.
That's already done. Even the latest SDK is already translated /flattened to Pascal. Important for synth plugins. Effects are perfectly OK in lower versions. Note the newer versions seem to be slower, more hardware demanding.
And I forgot the mention Frederic VanMol, who did the first translation for the VST client SDK and upon his work everything else is based. (But he worked/works for FL Studio) And I did the first host.

About speed:
There really is no difference, since most VST's are optimized with (B)ASM code anyway: you may be surprised though, that FPC actually performs better than Delphi because it has better FPU support, depending on processor type, of course. And with the correct settings. ( -Cf<XXX> ). Funny that here it actually pays off to use FPC instead of C++.
FPC can be highly efficient on vector processing (buffer calculations included) if you know how to handle processor specific optimizations.

When using the LLVM back-end the results should be even better - completely equal to llvm C++ -, although I did not write a VST since 7 years.
« Last Edit: December 06, 2019, 09:27:02 am by Thaddy »
Specialize a type, not a var.

syntonica

  • Full Member
  • ***
  • Posts: 120
Re: Interfaces/Polymorphism
« Reply #12 on: December 06, 2019, 09:23:12 am »
I've got his VST 2.3 SDK Pascal translation lying around here somewhere. I'll have to update it to 2.4, but most of the heavy lifting is done.
That's already done. Even the latest SDK is already translated /flattened to Pascal. Important for synth plugins. Effects are perfectly OK in lower versions. Note the newer versions seem to be slower, more hardware demanding.
And I forgot the mention Frederic VanMol, who did the first translation for the VST client SDK and upon his work everything else is based. (But he worked/works for FL Studio) And I did the first host.
My Google Fu must be lacking, as I had to scrape to get the 2.3 version....  :) Can you point me in the right direction?

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11382
  • FPC developer.
Re: Interfaces/Polymorphism
« Reply #13 on: December 06, 2019, 10:05:30 am »
Probably because the most used form of interfaces is reference counted. ("smart pointer").

Oh! Okay! I was hoping I wasn't missing anything and it looks like I was, sort of. I'll have to watch out for that since I prefer malloc/free over RC.

Interface problems are largely due to RC. Mostly because most have a trial and error way of working, which usually aligns well with Pascal/Delphi, but this is an exception :-)

This because only interface references are automatically refcounted and the corresponding object references are not. They have a ref count for interface usage (the last reference via an interface disappearing will deallocate), but object references does.

As manual vs refcounted goes, in general I'm pro manual allocation, but not a purist, IOW they will have to pry refcounting strings from my cold, dead hands :-)   

Quote
If it's a success, I will definitely share the unit and it will be my contribution to putting another stake in the heart of Carbon. If it had been written in anything other than Pascal, wouldn't we all be Cocoaized by now?

Cocoa had a name of being buggy and having versioning problems for a long time. Also it was not a plain C app, so a lot of Objective C interfacing had to be arrange to make it practical. (you did check out the objective Pascal dialect didn't you?) . It also was an enormous amount of work, and little comparison material.

Carbon just worked, and was usable as fundament for long term libraries and frameworks. Even Adobe postponed the migration several times ( and eventually went with a cloud version)

Note that since development versions of Lazarus have a cocoa port, lazarus LCL is a form of GDI/cocoa abstraction already. Rebasing your framework on top of it could be worthwhile

p.s. the cloud thing is a joke, I don't think that is related to cocoa.
« Last Edit: December 06, 2019, 10:23:30 am by marcov »

avra

  • Hero Member
  • *****
  • Posts: 2514
    • Additional info
Re: Interfaces/Polymorphism
« Reply #14 on: December 06, 2019, 10:11:55 am »
My first project will be porting over my VST plugin from C++ for both Mac and Windows
There is pl_AsioVST package which you can install via OPM which can help you to create VST plugins or ASIO applications. There are many included built in filters to built effects without much DSP knowledge. I am not quite sure, but I think it's only for Windows. It's a Lazarus port of this Delphi package: https://sourceforge.net/projects/delphiasiovst/
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

 

TinyPortal © 2005-2018