Are FPC definitions (such as records and functions) supposed to match Delphi's ?

[440bx]

Hello,

I've run into some record and function/procedure definitions that don't match Delphi's.  Is this something that is of no concern or are such differences considered something that should be "corrected" in FPC ?

[Thaddy]

FPC only tries to guarantee that in mode Delphi the record syntax is a fully  Delphi compatible subset of the possibilities that FreePascal may offer. So a piece of Delphi record code should compile in FPC mode Delphi, but a FreePascal declared record in mode Delphi should not necessarily compile in Delphi. AFAIK right now it is not an issue and it works both ways, depending on Delph version and/or {$modeswitch}, because advanced records are a newer feature, as are class  operators and Delphi doesn't know management operators.. (they got dropped from the release 10.3)

So Delphi code should work, the other way around is not guaranteed. (which even I find annoying, but learned to respect it)

If your case is outside of the above, please show a small but full example that reproduces your issue.

[440bx]

If your case is outside of the above, please show a small but full example that reproduces your issue.

Here is an example.  FPC defines the macro:

Code: Pascal  [Select][+][-]

1. function Header_Layout(hwndHD:HWND;var layout : HD_LAYOUT) : WINBOOL;
2. begin
3.   Header_Layout:=WINBOOL(SendMessage(hwndHD,HDM_LAYOUT,0,LPARAM(@layout)));
4. end;
5.  

in Delphi, instead of using a "var" for layout, the definition uses a pointer. That causes a parameter mismatch.

related to that, the definition of HD_LAYOUT in FPC is like this:

Code: Pascal  [Select][+][-]

1.      HD_LAYOUT = record
2.           prc : ^RECT;
3.           pwpos : ^WINDOWPOS;
4.        end;
5.  

in Delphi, it goes like this

Code: Pascal  [Select][+][-]

1.   THDLAYOUT = record
2.     Rect        : PRECT;
3.     WindowPos   : PWINDOWPOS;
4.   end;
5.   PHDLAYOUT = ^THDLAYOUT;
6.  

things like that.  Sometimes, as shown above, the field names are different.  Delphi didn't follow MSDN naming whereas FPC did. Which "standard" is the favored one in such cases, Delphi or MSDN ?

[Thaddy]

But that is not a record syntax issue, but a record winapi implementation issue: that's a known fact. Both these record types are valid in both language dialects, but FPC has a "quirky" way of implementing winapi. You can use the JEDI units if you do not agree with the standard way of declaring Windows API's in FPC.
(Note the "quirky" way is essentially more correct and you can also copy paste the Delphi declarations to your own code. FPC tends to use strict C syntax equivalents which can be a huge p in the a)

Against the naming you can file a bug report.  It is not a compiler issue.

BTW I also often complain  about Pointers to vs var parameters if it is clear var is the real meaning. Deaf ears. Anyway, it compiles either way. Not easy for noobs but just adjust your code or use the JEDI version (or even the Delphi provided windows units!! these compile after a few bug fixes on their side)

[lucamar]

But that is not a record syntax issue, but a record winapi implementation issue [...]

He didn't say he had a syntax problem, but a definition problem. The thread title says it quite clearly: FPC record and function definitions which don't match Delphi's ones.

It's true that they are basically equivalent (couldn't be otherwise) but having the definitions match would make easier both: having dual-compilable code and transferring Delphi code to FPC (and viceversa).

[marcov]

Mostly I follow MSDN, but implement workarounds for delphi for certain high profile cases. (iow if a much used component like e.g. VST hits it. Then every porting event just reraises the same discussion).

Workarounds are things like overloads or case-records (unions).

[Thaddy]

Mostly I follow MSDN, but implement workarounds for delphi for certain high profile cases. (iow if a much used component like e.g. VST hits it. Then every porting event just reraises the same discussion).

Workarounds are things like overloads or case-records (unions).

With all respect, - you know that! - what you do is indeed follow the C syntax on msdn, whereas the Delphi translations take into account impossibilities like a Pointer not being nil and chooses a var instead of a pointer instead. Which is actually optimal language use. You often can't do that easily (macro's, Marco  ) in C, but you can do it in Pascal. Underused strength of the language in the windows api part.

[marcov]

With all respect, - you know that! - what you do is indeed follow the C syntax on msdn, whereas the Delphi translations take into account impossibilities like a Pointer not being nil and chooses a var instead of a pointer instead.

Well, that is one would hope. Without a public source, preferably usable in an automated matter, it is simply no contest. MSDN is open and fairly unambiguous, headers are semi automatically translatable.

So basically, yours is a philosophical point(and with an IMHO too positive view on Delphi header translations, I might add), mine a practical one.

The only other option is to one-by-one change everything to Delphi syntax, with umpteen breakages per release. No thank you.

Correcting obscure API references with ifdefs hurts Lazarus/FPC users more than Delphi users, since they must make a version dependent ifdef, and each case the exact version of the change must be determined.

While a minor change only needs one simple ifdef FPC, and problematic cases get preferential treatment, reducing those actual problems with magnitudes.

[BeniBela]

Clearly in this case it should neither be a pointer nor a var, but an out parameter

[440bx]

... but having the definitions match would make easier both: having dual-compilable code and transferring Delphi code to FPC (and viceversa).

Yes, that's the crux of the matter.  When definitions don't match, porting from Delphi to FPC can really take some time.

Mostly I follow MSDN, but implement workarounds for delphi for certain high profile cases.

That answers the question.  The MSDN definition is _generally_ the "standard" while the Delphi definitions may or may not be "accommodated" depending on the case.

I won't report discrepancies of that kind.

Thank you Marco.