C++ Classes in Delphi/FreePascal

[savage]

Maybe I have missed something here, but I thought that FreePascal is not able to create DLLs/SOs yet? I thought that was the main issue as to why Lazarus does not load it's components dynamically, hence why the whole IDE is compiled everytime a component is added.

Don't confuse this with the fact that FreePascal CAN access/interact with DLLS, but I don't think it can create them.

Can anyone from the FreePascal community confirm or deny the ability to create DLLs/SOs using FreePascal? Oh yeah, and if it can't, when the hell will they add that in .


Thanks.

[Marco]

FPC has some rudimentary DLL and PIC support. However it is not always userfriendly. (read: slight mod might break dll compability)

FPC afaik has no full C++ support yet, though theer has been toyed with that in the past. There is no C++ mangling yet, and it is not yet clear which C++ compiler to support anyway (gcc is most likely, not BCB or VC++)

[Lightning]

FPC can compile .so/.dll with no problems, the problem here is name mangling changes from one GCC release to another (i think i will kill those GCC developers, just joking ) and i don't know if C++ classes are compatible with FPC ones, i don't think GCC classes are compattible with BCB or VC++ classes, most libs don't export classes for another language, look at windows .dlls all export functions not classes.
Talk to the FPC team for more info on this.

[savage]

Ok I am lost guys. If FPC does support creating DLLs and SOs then why doesn't Lazarus use them to dynamically load DLLs as part of the IDE, for it's component architecture? What am I missing here?

[Lightning]

It will, it's in the "planning stage" for some time now, recently i needed to make browser plugins that will work in any browser on any OS and i found the XPCOM technology used by almost all browsers except IE wich uses COM(ActiveX), XPCOM is OpenSource unlike ActiveX wich is proprietary.
This technology could be used as base to the IDE packages wich are plugins, of course it sounds simple and it is but a lot of work is needed and there are simply to few programmers to do it.
I'm one of those wich loves IDE packages and i plan to add them myself if i have some time and of course after i complete the things on my ToDo list like the plugins i was talking about

[marcov]

Ok I am lost guys. If FPC does support creating DLLs and SOs then why doesn't Lazarus use them to dynamically load DLLs as part of the IDE, for it's component architecture? What am I missing here?

More advanced features, that make up the difference between dll and
packages:
- unified memmanager over dynamic parts (sharemem unit in Delphi),
- avoiding that objects get one VMT in the DLL, and one in the .exe etc

You should see a FPC DLL now as a standalone program, with an own RTL that you can load and call. (a slight workaround via cmem exempt), not as a modular loadable part of your own mainprogram

[Clootie]

Back to original topic...

Couple of days ago when testing how D3DX9 loading of .X meshes with embedded hierachy working in FreePascal I've stumbled the same problem as Ultra: details of FreePascal implementation of VMT are different to C++ / TurboPascal / Delphi ones. In Delphi/C++ first virtual method is allocated in VMT with Offset == 0, but in FreePascal it has positive offset of 80 bytes. :twisted:

I found a solution to this problem, althrow not very elegant, but at least working. In mine case I've needed to export Pascal class to C++ code. First I've thought about patching class so Self will be pointing to "correct" method, but in this case Pascal code will loose ability to access class data members. Finally I've decided to use interfaces feature of object pascal (not least due to both mine C++ headers and Ultra ones pretend to be using some kind of COM incompatible interfaces ).

So for Ultra case solution will be:
[pascal][background=#FFFFFF][normal=#000000][number=#0000FF][string=#0000FF][comment=#248F24][reserved=#000000]
// MyClass.pas
type
IMyClass = interface
public
procedure DoSomething; virtual; cdecl; abstract;
end;

// pasdll.dpr
procedure InitDll(const MyClass: IMyClass); cdecl;
begin
// Before using MyClass patch interface to skip IUnknown fields - not needed in our case
// WARNING: you should NOT assign MyClass to other interfaces, as it's not REAL COM INTERFACE!!!
Dec(PInteger(MyClass)^, $C);

MyClass.DoSomething;

// After using - restore interface VMT
Inc(PInteger(MyClass)^, $C);
end;

exports
InitDll name 'InitDll';
[/pascal]

In case you need to pass Pascal "interface" to C++ (as I needed) you should perform reverse operation: Inc Self pointer before passing to C++ code, and Dec it after call. There are some other implementation details in this case - I'll later post excerpts from mine code to demonstrate complete solution.

[Clootie]

OK, after complaining on this compatibility issue of FPC-dev mail list, another solution was proposed to me... FreePascal allows to define "raw" interfaces - interfaces which do not include IUnknown by default. Side effect of these interfaces is that automatic management (reference counting) of these interfaces is disabled, but it's really a plus in our cituation.

So, final result looks like this (again for Ultra's case):
[pascal][background=#FFFFFF][normal=#000000][number=#0000FF][string=#0000FF][comment=#248F24][reserved=#000000]// MyClass.pas
type
{$INTERFACES CORBA}
IMyClass = interface
procedure DoSomething; cdecl;
end;
{$INTERFACES DEFAULT}

// pasdll.dpr
procedure InitDll(const MyClass: IMyClass); cdecl;
begin
MyClass.DoSomething;
end;

exports
InitDll name 'InitDll';
[/pascal]
But remember this will not work in Delphi!

[Anonymous]

Back to original topic...

Couple of days ago when testing how D3DX9 loading of .X meshes with embedded hierachy working in FreePascal I've stumbled the same problem as Ultra: details of FreePascal implementation of VMT are different to C++ / TurboPascal / Delphi ones. In Delphi/C++ first virtual method is allocated in VMT with Offset == 0, but in FreePascal it has positive offset of 80 bytes. :twisted:

This is a known incompability, and there is not much that can be done about it, since it is a limitation of the GNU linker, to not be able to use negative offsets to a symbol.

I understand how the workaround works, but I have no idea how general it is.