I have the following:

unit foo;
{$mode objfpc}{$H+}
interface
uses
  foobar;
function BitCnt(ABitmap: TBitBoard): Integer;
implementation
{$ifdef cpu386}
function BitCnt(ABitmap: TBitBoard): Integer; assembler; register; nostackframe;
asm
  ...
end;
{$else}
function BitCnt(ABitmap: TBitBoard): Integer; inline;
begin
  ...
end;

This seems to compile and work as intended, no matter which of the two implementations I choose. But I wonder how this can work? I always thought that what is written in the interface section is authoritative. How can the compiler properly use this unit and call the function when the implementation actually implements a completely different calling convention (inline) than the one that is declared in the interface section?

Bernd

Inline is not a calling convention, nor does it affect the calling convention.

Jonas

2011/12/16 Jonas Maebe :

Inline is not a calling convention, nor does it affect the calling convention.

You are right, its not a calling convention and declaring a different convention in the implementation indeed does not work.

But I am still surprised that inline can be declared in either of the two sections ( I am not complaining, I am actually glad it works for my particular application). Is there any recommended style, is it bad practice to put it into the implementation? (I'm not totally sure whether I should conceptually regard inline as an implementation detail or as something that belongs into the interface section since it affects the generated code of other units)

Bernd

Bernd wrote

But I am still surprised that inline can be declared in either of the two sections ( I am not complaining, I am actually glad it works for my particular application). Is there any recommended style, is it bad practice to put it into the implementation?

Keeping the interface and implementation declarations the same is the best approach. Inline currently always changes the definition anyway (as far as the compiler is concerned) because the implementation becomes part of the definition once it's parsed. In the future, this may however change to prevent unexpected recompilations (http://bugs.freepascal.org/view.php?id=19673 ).

Jonas

Another thing freepascal allows is for OVERLOAD to be declared one place but not the other. Delphi is more strict in this regard. Also delphi is more strict when it comes to PROGRAM name parsing. In freepascal the program name can mismatch the file name, whereas delphi stops compiling and tells you error.

In other cases, freepascal is more strict than delphi. I think Wirth would prefer pascal to be as strict as possible, but sometimes being so strict makes the language less convenient. I don't know. Another thing I noticed is you can just use a begin and end for freepascal without PROGRAM declaration at the top of the program.. again less strict than delphi. In the freepascal unit tests I think they are all just begin/end programs without the program declaration at the top of each file. Possibly more convenient for developers. Wirth would complain and say that's not strict enough. I personally don't know what the best route to choose is. Sometimes convenience is better. Other times I would like to stick to strict.

i've never known this (program name must equal filename) to be a requirement... but then again, i've never used delphi... i have, however, used TP2 thru TP/BP7 and in a world stricken with 8.3 filename limitations, being able to have something like

PROGRAM TestMonitorResolutions

with a filename of montest.pas was a GoodThing<tm>... why this would ever change simply because we can use long filenames is completely beyond me <smh>

Possibly it was Unit names and not program names, my memory may not serve me well. I came across issues when compiling some code once, and there was something different between compilers like unit name strictness.

The problem with allowing any sort of syntax is that your code is not portable, different compilers might not accept it, where others will accept it. This can lead to people creating hundreds of files that compile with one compiler but not another. That's one advantage of defining a language standard.

Another thing freepascal allows is for OVERLOAD to be declared one place but not the other. Delphi is more strict in this regard.

That's fixed in svn trunk.

As Waldo Kitty mentioned, that's incorrect. And both FPC and Delphi require that unit names match the file name (except in case the FPC parameter -Un is used, and FPC also allows partial matches based on the first 8 characters of the unit/file name to accomodate 8.3 file systems).

Another thing I noticed is you can just use a begin and end for freepascal without PROGRAM declaration at the top of the program.. again less strict than delphi.

Delphi also allows that. Even gpc allows it, although it prints a warning.

Jonas