Re: [fpc-pascal] Type-casting a class variable

[Sven Barth via fpc-pascal]

Adriaan van Os via fpc-pascal  schrieb am
Mi., 1. Mai 2024, 17:07:

> Suppose I have a
>
> var myClass: TClass
>
> and (for example) a
>
> class function TWindow.CreateNewWindow( )
>
> Now I want to call CreateNewWindow for var myClass. Of course, depending
> on the class,
> CreateNewWindow will behave different. Type-casting myClass to TWindow
> crashes (in my setup). And
> even if it worked, wouldn't it loose the class information ?
>

In addition to what Martin said: as long as you have a non-static class
method the value of the variable you call the class method on (e.g. myClass
in your example) will be passed as Self parameter. So no need for extra
parameters.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] AnsiString address changed

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Mo., 18. März 2024, 13:30:

>
>
> > On Mar 18, 2024, at 5:29 PM, Michael Van Canneyt via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > Of course there must be, that's the whole point of copy-on-write.
> >
> > As soon as one reference is changed, a copy is made if the reference
> count
> > is larget than 1, and this copy is changed.
>
> Oh, it does copy on write. I see now that by looking at the pointer
> addresses.
>
> So what happens if you do this? s2 is pointing to s1 but then you change
> the size of s1 and ReAllocMem gets called and invalidates the pointer to
> the original s1. How does s2 know this and not access corrupted memory now?
>
>   s1 := '123';
>   s2 := s1;
>   s1 := '';
>


Your description is inaccurate: s2 does not point to s1. Instead both point
to the string data with a reference count of 2. If you now change one of
the two (e.g. with SetLength) then a copy of the string data will be
created and that copy will be manipulated.
The memory of the string data will only be reallocated if only one
reference to that data exists.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Floating point question

[Sven Barth via fpc-pascal]

James Richters via fpc-pascal  schrieb am
Di., 20. Feb. 2024, 04:42:

> I don't know why it would be different in Windows than on Linux.


If you're using Win64, then the answer is simple: x86_64-win64 unlike any
other x86 target does not support Extended, so neither the compiler nor the
code in runtime will ever calculate anything with that precision.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Can FPC link a program with static (.a) libraries on Windows

[Sven Barth via fpc-pascal]

Tony Whyman via fpc-pascal  schrieb am
Sa., 17. Feb. 2024, 00:50:

> I have a Pascal program, compiled with FPC 3.2.2 and which appears to
> happily link and run with a static library compiled with gcc and having
> a ".a" prefix on linux. The functions in the static library and declared
> as external functions using the "external  name  name>" directive. The "".a" library is copied to the same directory as
> the program unit before compiling and linking.
>
> However, compiling the same program on Windows always seems to result in
> the loader complaining that the corresponding .dll is not
> present, indicating that instead of linking with the static library, the
> program is attempting to "statically" load the correspoinding dll at
> initialisation time.
>
> I have tried to force it to link with the static library (e.g. using the
> -Xt command line switch) but no luck.
>
> Hence the question, does FPC 3.2.2 support linking with static libraries
> on windows?
>

"external  name " is for dynamic linking. For static
linking you need to leave out the  and instead use "{$linklib
}" or even "{$linklib , static}" . That will also work on
Linux.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] "Unexpected end of file" when having an open comment after the final "end."

[Sven Barth via fpc-pascal]

Ralf Quint via fpc-pascal  schrieb am Fr.,
9. Feb. 2024, 20:36:

> On 2/8/2024 11:01 AM, Martin Wynne via fpc-pascal wrote:
> > Hi Thomas,
> >
> > The error is not the file content after "end.".
> >
> > The error is not having the expected "end;" after "begin".
> >
> > This works ok:
> >
> > _
> >
> > program test;
> >
> > begin
> > end;
> >
> > end.
> >
> > abc 123
> >
> > _
> >
> > Martin.
>
> This is not a valid Pascal source code to begin with (pun intended)...
>
> The "begin" is the start of the actual Pascal program and by definition,
> that program is terminated by matching that with an "end." That's what
> the code completion in Lazarus for example is adding into a new "simple
> program" project source code.
>
> Just adding a random "end;" should also just yield an error message...
>
> Well, I actually did just tested this and it gives as expected an
> "Error: Syntax error,  "." expected but ";" found. It Doesn't even
> process past the "end." in that case.
>

That's what I had expected.


> What is however interesting is that an open comment, as mention by the
> OP,  immediately after the "end." results in the "Error: unexpected end
> of file" message, however any other addition text past that "end." will
> result in no error message and completing to compile the program
> successfully...
>
> I just tried a couple more things, and it seems it is just the "{" or
> "(*" opening of a comment that is causing the error message, having a
> "//" comment until end of  line after the "end."  will also compile just
> fine
>

If one knows how the compiler is structured (I do) then it isn't that
surprising that it behaves that way with a dangling comment due to the
interaction between the scanner (which is responsible for the comments) and
the parser (which triggers the consumption of the final point).
The problem is that the parser does not know that the end of the program
has been reached when that point is consumed and happily searches for the
next token, consuming all whitespace and comments along the way.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] "Unexpected end of file" when having an open comment after the final "end."

[Sven Barth via fpc-pascal]

Martin Wynne via fpc-pascal  schrieb am
Do., 8. Feb. 2024, 22:03:

> Hi Thomas,
>
> The error is not the file content after "end.".
>
> The error is not having the expected "end;" after "begin".
>
> This works ok:
>
> _
>
> program test;
>
> begin
> end;
>
> end.
>
> abc 123
>

If that works then that is a bug as well, because the begin of the main
*must* be terminated with a "end.", not a "end;".

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] "Unexpected end of file" when having an open comment after the final "end."

[Sven Barth via fpc-pascal]

Thomas Kurz via fpc-pascal  schrieb am
Do., 8. Feb. 2024, 13:31:

> Hello all,
>
> I'm unsure about whether or not to report this as a bug. Imho, it is a
> bug, but maybe there's a good reason to handle this.
>

Please report a bug.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Need some advice

[Sven Barth via fpc-pascal]

ppadilcdx via fpc-pascal  schrieb am Mi.,
24. Jan. 2024, 22:07:

> Thanks for that, now it compiles but it doesn't work, i.e. I added a
> pair and value and then used trygetdata and it can't find it. So perhaps
> I'm missing something else :
>

Your operator needs to establish a true order between the two passed in
values. Right now your operators only check a, but not b. That is wrong and
thus the map won't work correctly.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] IntToStr implementation

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Do., 18. Jan. 2024, 00:44:

>
>
> > On Jan 17, 2024, at 10:15 PM, Marco van de Voort via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> >
> > Op 17-1-2024 om 15:57 schreef Hairy Pixels via fpc-pascal:
> >> Can anyone show me where to find the IntToStr implementation in
> SysUtils? There's so many level of indirection and macros I have no idea
> where to look for it!
> >
> > Grep rtl/objpas/sysutils for it.
> >
> >
> > sysstr.inc for the implementation sysstrh.inc for the declaration
> >
>
> Which then goes to System.Str(), where is that? I found some other Str
> functions in a lstrings.pas file but I don't think that's it. All the
> macros break code tools for me and I can't find anything.
>

There is no source for Str() in that sense, because Str() is a compiler
intrinsic implemented in the compiler's ninl.pas.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] What's in Hello World

[Sven Barth via fpc-pascal]

Am 07.01.2024 um 11:39 schrieb Michael Van Canneyt via fpc-pascal:



On Sun, 7 Jan 2024, Sven Barth via fpc-pascal wrote:


Am 07.01.2024 um 10:01 schrieb Florian Klämpfl via fpc-pascal:



Am 06.01.2024 um 20:05 schrieb Matthew Phillips via fpc-pascal 
:


I compiled the Hello World program from the docs and noticed that it's
435k. Compared to a lot of newer languages, like Golang, that's not 
bad

at all.

I then compiled the equivalent C program with gcc which came out at
33k. So I'm just curious, where does the difference comes from?
Could it be that fpc is including some parts that are not being 
used in

this simple of a program or is more going on?


https://wiki.freepascal.org/Size_Matters

To underline this with some numbers (I assume you mean the 
demo/text/hello.pp which only contains a mere "Writeln('Hello 
World')" and no additional units; all tests on x86_64-linux with 3.3.1):


- FPC compiled as is: 388976 B
- FPC compiled with full smartlinking: 55920 B
- FPC compiled with C linkage: 388760 B
- FPC compiled with full smartlinking and C linkage: 56792 B


Maybe it is a good idea to add these numbers to the above WIKI page, 
to quantify

the discussion and to illustrate what the effect is of various options.


Probably... 路‍♀️

And just for the fun of it, the size if the RTL is compiled into a 
dynamic package and that is used:


- no smartlinking: 15784 B
- with smartlinking: 15608 B

With the librtl.so having a size of 649912 B which will ammortize itself 
if multiple applications use dynamic packages.


I think we should also explain why linking to C has almost no effect 
on actual binary size.


That's mainly because the functions that differ between FPC_USE_LIBC and 
not are rather slim syscalls anyway, so the main bunch of Pascal code is 
still the same in both cases.


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] What's in Hello World

[Sven Barth via fpc-pascal]

Am 07.01.2024 um 10:01 schrieb Florian Klämpfl via fpc-pascal:



Am 06.01.2024 um 20:05 schrieb Matthew Phillips via fpc-pascal 
:


I compiled the Hello World program from the docs and noticed that it's
435k. Compared to a lot of newer languages, like Golang, that's not bad
at all.

I then compiled the equivalent C program with gcc which came out at
33k. So I'm just curious, where does the difference comes from?
Could it be that fpc is including some parts that are not being used in
this simple of a program or is more going on?


https://wiki.freepascal.org/Size_Matters

To underline this with some numbers (I assume you mean the 
demo/text/hello.pp which only contains a mere "Writeln('Hello World')" 
and no additional units; all tests on x86_64-linux with 3.3.1):


- FPC compiled as is: 388976 B
- FPC compiled with full smartlinking: 55920 B
- FPC compiled with C linkage: 388760 B
- FPC compiled with full smartlinking and C linkage: 56792 B

(gotta admit, the last one surprised me though ^^')

Regards,
Sven___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to avoid Copy

[Sven Barth via fpc-pascal]

Amir--- via fpc-pascal  schrieb am Mi., 3.
Jan. 2024, 07:53:

> Yeap! That is actually what I posted here (Feature Request)
> .
>

My example allows you to access it right now with the existing FPC release.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to avoid Copy

[Sven Barth via fpc-pascal]

Am 31.12.2023 um 04:11 schrieb Amir--- via fpc-pascal:


On 12/30/23 00:20, Sven Barth via fpc-pascal wrote:
Amir via fpc-pascal  schrieb am Sa., 
30. Dez. 2023, 08:11:




On Dec 29, 2023 9:50 PM, Adriaan van Os  wrote:

Amir--- via fpc-pascal wrote:
> Hi all,
>
>  I have a List of record, where the record has a WideString
field.
>   I have some code like the following:
>
> function check(constref v: TMyRecord; data:
TListOfMyRecord): Boolean;
> var
>   r: TMyRecord;
>
> begin
>   Result := False;
>   for r in data do
> if r.State = v.State then
>   Exit(True);
> end;
>
> I call this method a lot and the CPU profiling shows a lot
of cpu time
> spent on "fpc_copy_proc" (which I assume is doing the deep
copy on
> records) from "TCustomListEnumerator.GetCurrent".
> I considered other alternatives like using enumerators but
they all need
> a to return a record (and hence copying the widestring field).
> I can think of two solutions to get rid of the wasting(!)
so much time
> on "fpc_copy_proc":
> 1) Changing the TMyRecord to TMyClass. But then I need to
Create and
> Free a "lot" of objects.
> 2) Update TListOfMyRecord to TListOfPointerToMyRecord. This
requires a
> "lot" of memory allocation/fragmentation.
>
> Is there a better solution?

Pass the data parameter by reference.

This means I need to have a ListOfMyRecord and a
ListOfConstRefMyRecord, right?


No, that's not a thing.

You simply need to declare your "data" parameter as "constref" or 
"const" as well, just like your "v" parameter.

Have a look at this piece of code (The complete code is attached):
type
  TMyRecord = record
    Str: AnsiString;
    Index: Integer;

  end;
  PMyRecord = ^TMyRecord;

  TMyList = specialize TList;
  TMyPtrList = specialize TList;

function Check1(const MyList: TMyList): Integer;
var
   data: TMyRecord;

begin
  Result := 0;
  for data in MyList do
    if data.Index mod 100 = 0 then
  Inc(Result);

end;

function Check2(MyList: TMyList): Integer;
var
   data: TMyRecord;

begin
  Result := 0;
  for data in MyList do
    if data.Index mod 100 = 0 then
  Inc(Result);

end;

function Check3(MyPtrList: TMyPtrList): Integer;
var
   data: PMyRecord;

begin
  Result := 0;
  for data in MyPtrList do
    if data^.Index mod 100 = 0 then
  Inc(Result);

end;


I compiled the code with `fpc -O3 -Sd -gv -g -gl ` and ran `valgrind` 
on it (the output is attached). It does not look like there is a big 
difference between the Check1 and Check2 but Check3 is about 20 times 
faster than the other two.


For a class type there isn't much difference between being passed as 
"const" or not. It's mainly records and managed types this affects.


I believe the issue could be resolved if we make 
"TCustomListWithPointers.GetPtrEnumerator" a public method. Then, one 
can implement the following function:


function Check4(MyList: TMyList): Integer;

  it := MyList.GetPreEnumerator;
  while it.MoveNext do
  begin
    if it.Current^.Index mod 100 = 0 then
 
  end;


You simply need to inherit from the list class so that you can make the 
function public. And with a little trick you can also use it inside a 
for-in-loop:


=== code begin ===

program tlistitr;

{$mode objfpc}{$H+}
{$modeswitch advancedrecords}

uses
  Generics.Collections;

type
  TRec = record
    a, b, c: Int64;
    constructor Create(aArg1, aArg2, aArg3: Int64);
  end;

  { this way the GetPtrEnumerator function is available; you could also 
use a class helper }

  TMyList = class(specialize TList)
  public
    function GetPtrEnumerator: specialize TEnumerator;
  end;

constructor TRec.Create(aArg1, aArg2, aArg3: Int64);
begin
  a := aArg1;
  b := aArg2;
  c := aArg3;
end;

function TMyList.GetPtrEnumerator: specialize TEnumerator;
begin
  Result := inherited GetPtrEnumerator();
end;

{ with this you can simply do "for PtrTypeVar in List.GetPtrEnumerator do",
  though this *might* not work in mode Delphi... }
operator Enumerator(aEnum: specialize TEnumerator): 
specialize TEnumerator;

begin
  Result := aEnum;
end;

var
  l: TMyList;
  r: TRec;
  p: TMyList.PT;
begin
  l := TMyList.Create;
  l.Add(TRec.Create(1, 2, 3));
  l.Add(TRec.Create(9, 8, 7));
  for p in l.GetPtrEnumerator do begin
    Writeln(p^.a, ' ', p^.b, ' ', p^.c);
  end;
end.

=== code end ===

Regards,
Sven___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to avoid Copy

[Sven Barth via fpc-pascal]

Am 01.01.2024 um 16:51 schrieb Wayne Sherman via fpc-pascal:

On Mon, Jan 1, 2024 at 6:14 AM Hairy Pixels wrote:

On Jan 1, 2024, at 3:50 PM, Michael Van Canneyt wrote:
You can't optimize that. As said, a generic is convenient but slow.

I don't know about that. Like was mentioned the enumerator needs to return a
pointer, preferable without ^ so it feels like a record and only use that in 
the for-in
scope. You can kind of do that yourself but it's cumbersome to maintain and
missing from the RTL (maybe for this reason).

Modern Pascal compilers already do this for certain types and pass by
reference parameters.  For example, AnsiString variables and variables
of type class are handled internally as pointers, but manipulated
opaquely without explicit pointer notation.  A record passed as a var
or constref parameter is internally a pointer, but does not require
the code writer to handle it explicitly as such.
That kind of concept only exists in Pascal for parameters, but not for 
variables or result values as would be needed for this.


Regards,
Sven___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to avoid Copy

[Sven Barth via fpc-pascal]

Amir via fpc-pascal  schrieb am Sa., 30.
Dez. 2023, 08:11:

>
>
> On Dec 29, 2023 9:50 PM, Adriaan van Os  wrote:
>
> Amir--- via fpc-pascal wrote:
> > Hi all,
> >
> >  I have a List of record, where the record has a WideString field.
> >   I have some code like the following:
> >
> > function check(constref v: TMyRecord; data: TListOfMyRecord): Boolean;
> > var
> >   r: TMyRecord;
> >
> > begin
> >   Result := False;
> >   for r in data do
> > if r.State = v.State then
> >   Exit(True);
> > end;
> >
> > I call this method a lot and the CPU profiling shows a lot of cpu time
> > spent on "fpc_copy_proc" (which I assume is doing the deep copy on
> > records) from "TCustomListEnumerator.GetCurrent".
> > I considered other alternatives like using enumerators but they all need
> > a to return a record (and hence copying the widestring field).
> > I can think of two solutions to get rid of the wasting(!) so much time
> > on "fpc_copy_proc":
> > 1) Changing the TMyRecord to TMyClass. But then I need to Create and
> > Free a "lot" of objects.
> > 2) Update TListOfMyRecord to TListOfPointerToMyRecord. This requires a
> > "lot" of memory allocation/fragmentation.
> >
> > Is there a better solution?
>
> Pass the data parameter by reference.
>
> This means I need to have a ListOfMyRecord and a ListOfConstRefMyRecord,
> right?
>

No, that's not a thing.

You simply need to declare your "data" parameter as "constref" or "const"
as well, just like your "v" parameter.

Note: prefer the use of "const" instead of "constref" unless you really
need a reference, because the compiler will then pick the optimal way to
pass the value (e.g. small ones will be passed by register instead of as an
address).

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Procedures that work like WRITELN()

[Sven Barth via fpc-pascal]

Am 27.12.2023 um 12:25 schrieb James Richters via fpc-pascal:


I wanted to write what I thought should be a simple procedure, just 
instead of calling WRITELN() with some arguments,


call WRITELOG() with the same arguments that you would use to write to 
a file, but my WRITELOG() procedure would


write to the screen and the file.. but I can’t figure out how to pass 
all the arguments to the two WRTIELNs.


So….

Procedure WriteLog(Filename:String, AllOtherAurguments:);

Begin

Writeln(Filename,AllOtherAurguments);

Writeln(AllOtherAurguments);

End;

How can I make this work?Since WRITELN can take any number of many 
kinds of arguments,


how can I get them all and pass them along without knowing how many or 
what types they are?


How does WRITELN even work when you don’t know this information?

I’m guessing there should be some way to do this, because WRITELN 
itself works, but how it could


possibly work is not within my experience.

The only way I could think of would be if there were versions of 
WRITELN with every combination


of possible arguments, but that seems completely unmanageable and 
ridiculous,


so there must be something more advanced going on, but maybe WRTELN is 
special and not something I can duplicate?




Write(Ln) is a compiler intrinsic and thus can behave in ways that are 
not possible for ordinary functions.


Your only ways are either to use "array of const" like "Format" does or 
write a text file driver as is done in the StreamIO unit which allows to 
assign a Stream to a TextFile that can in turn be used as the file 
parameter of Write(Ln). You can implement any other output through this.


Regards,
Sven___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Read Field names from VMT

[Sven Barth via fpc-pascal]

Am 26.12.2023 um 21:29 schrieb Amir--- via fpc-pascal:


On 12/26/23 01:14, Sven Barth via fpc-pascal wrote:
Amir--- via fpc-pascal  schrieb am 
Di., 26. Dez. 2023, 07:03:


Hi,

   I want to retrieve the name of the fields in a record/class,
at run
time. It looks like "TVmt.vFieldTable" is what I need. But I
cannot find
any documentation about how to explore the content of this table. I
appreciate any pointer.


This only works for published fields and only fields of type class or 
interface can be published.

That would work for me. How can I enumerate over those fields?


You can use the PVmtFieldTable and PVmtFieldEntry types from the TypInfo 
unit:


=== code begin ===

program tfield;

{$mode objfpc}{$H+}

uses
  TypInfo;

type
  {$M+}
  TSub = class

  end;

  TTest = class
  published
    fTest: TSub;
  end;

var
  vft: PVmtFieldTable;
  vfe: PVmtFieldEntry;
  i: SizeInt;
begin
  vft := PVmtFieldTable(PVMT(TTest)^.vFieldTable);
  Writeln(vft^.Count, ' field(s) with ', vft^.ClassTab^.Count, ' type(s)');
  for i := 0 to vft^.Count - 1 do begin
    vfe := vft^.Field[i];
    Writeln(i, ' -> ', vfe^.Name, ' @ ', vfe^.FieldOffset, ' of type ', 
vft^.ClassTab^.ClassRef[vfe^.TypeIndex - 1]^.ClassName);

  end;
end.

=== code end ===

=== output begin ===

PS C:\fpc\git> .\testoutput\tfield.exe
1 field(s) with 1 type(s)
0 -> fTest @ 8 of type TSub

=== output end ===

Side note: contrary to what I had originally written only classes, but 
not interfaces are allowed for published fields and they need to have $M 
enabled.


Regards,
Sven___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Read Field names from VMT

[Sven Barth via fpc-pascal]

Amir--- via fpc-pascal  schrieb am Di.,
26. Dez. 2023, 07:03:

> Hi,
>
>I want to retrieve the name of the fields in a record/class, at run
> time. It looks like "TVmt.vFieldTable" is what I need. But I cannot find
> any documentation about how to explore the content of this table. I
> appreciate any pointer.
>

This only works for published fields and only fields of type class or
interface can be published.

Anything more requires extended RTTI, which is not yet implemented in FPC
(it's already more or less ready in a merge request, but there's still the
one or other issue that needs to be addressed).

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] More syntax questions (part 3)

[Sven Barth via fpc-pascal]

Wayne Sherman via fpc-pascal  schrieb am
Mo., 25. Dez. 2023, 15:46:

> On Mon, Dec 25, 2023 Michael Van Canneyt wrote:
> > In short: To make a EBNF grammar which is 100% correct is not so simple
> > and will make the scheme extremely difficult to understand for a reader.
> > So I prefer to present a simpler version, and mention some limitations
> >  only in the text
> ...
> > There are simply so many exceptions and limitations that the 100% correct
> > diagram would be incomprehensible and needlessly complicated if you
> tried to
> > capture every aspect for the full 100%.
>
> If the EBNF grammar is only a guide provided as documentation for a
> human reader then you might want that.  But if the EBNF grammar is
> used to drive a parser then it needs to be fully complete, accurate,
> and machine readable (see below).
>

The grammar embedded in the documentation is just that: a guide.
Though that doesn't mean that Michael isn't trying to fix as many of the
points that Adriaan mentioned as reasonably possible, because there
obviously have been mistakes and oversights.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] method-definition

[Sven Barth via fpc-pascal]

Michael Van Canneyt via fpc-pascal 
schrieb am Sa., 16. Dez. 2023, 09:43:

> The requirement for parameters in record constructors I guess comes from
> C++ builder by Embarcadero.
> There are some limitations imposed by C++.
>
> Whether they could be dropped in FPC is something Sven Barth should answer.
>

We only "inherited" that for Delphi compatibility. Technically the compiler
could handle it without problems... 路‍♀️

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] case statement

[Sven Barth via fpc-pascal]

James Richters via fpc-pascal  schrieb am
Do., 14. Dez. 2023, 20:13:

> I didn’t know there was such a thing as OTHERWISE.  Is there any
> functional difference between OTHERWISE and ELSE?
>

"otherwise" is what had been defined by ISO Extended Pascal for the
cause-statement.

Aside from not having the else-problem mentioned in this thread there is no
functional difference.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Error when building fpc on aarch64-linux still not resolved

[Sven Barth via fpc-pascal]

Bo Berglund via fpc-pascal  schrieb am
So., 10. Dez. 2023, 01:19:

> On Thu, 16 Nov 2023 13:15:27 +0100, Bo Berglund via fpc-pascal
>  wrote:
>
> >I tried to post this to the devel list but it seems to have failed so now
> trying
> >the general list instead...
> >
> >See ticket:
> >https://gitlab.com/freepascal.org/fpc/source/-/issues/39295
> >
> >It was closed a year ago being purportedly resolved...
> >
> >But only for powerpc 64 bit...
> >
> >It is still there for aarch64-linux used by Pi-OS bookworm 64 bit, which
> is now
> >the recommended version...
> >
> >RaspberryPi is a very popular platform so a solution for that is needed.
> >
> >I have tried building (via fpcupdeluxe) several revisions of fpc up to and
> >including trunk, but all fail with the same error outlined in the ticket
> above.
>
> Soon 4 weeks and no reply to this...  :(
>
> I have now started using the Raspberry Pi5B with Pi-OS 64 bit bookworm and
> I
> cannot get past the linking error when building fpc from sources, I have
> tried
> the latest release 3.2.2 and also the pre-release 3.2.3 and 3.3.1 but all
> fail
> with the same error:
> undefined reference to `__libc_csu_init'
>
> So now I tested to download what I think might be the trunk:
>
> https://gitlab.com/freepascal.org/fpc/source/-/archive/main/source-main.tar.gz
>
> And with these sources the linker error disappears and the build all
> succeeds.
>
> Could you not just make an intermediate tag for a version where this fix
> has
> been solved for the arm64 architecture running aarch64-linux?
>

3.2.3 already contains the same fixes that main has for that problem.

And as I had written: I can not reproduce your problems as I can build and
run both 3.2.3 and main with the 3.2.2 release we provide on our download
locations.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] what is release plan for fpc?

[Sven Barth via fpc-pascal]

Bo YU via fpc-pascal  schrieb am Do., 7.
Dez. 2023, 12:58:

> Hi,
>
> I am sorry if this is not the right mail list to ask the question.
>
> I am helping to build fpc package on Debian riscv64 and found that:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052557
>
> Now fpc version on Debian is 3.2.2, so I think this is fpc upstream
> latest tag, right?
> and this should be confirmed from here also:
> https://www.freepascal.org/download.html
>
> But from https://gitlab.com/freepascal.org/fpc/source/-/tags, I
> noticed there many tags newer than 3.2.2. So Could I ask here one
> question, do we have a plan to release a new version from upstream?
>
> I believe the new release will contain riscv64/mips64el support, which
> will make it easy to bootstrap them on downstream distros like Debian.
> Otherwise, backporting the huge patchset(>16K lines patch) will be not
> acceptable by maintainers.
>

The support for rv64 is only available from 3.3.1 on (aka main) for which
currently no release is planned. Even if we would say right now that we'd
start release preparation (which we don't), then it would take around half
a year for it to be released.

The next version currently planned is 3.2.4 in a soonish time frame. At
least as far as I'm aware MIPS64 should be supported there. If there are
specific commits from main that would fix issues with that platform we
could potentially still merge them to the fixes branch.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Cannot build fpc on Raspberry Pi4B running PiOS 64 bit (aarch64 Linux)

[Sven Barth via fpc-pascal]

Bo Berglund via fpc-pascal  schrieb am
Sa., 25. Nov. 2023, 08:19:

> On Tue, 21 Nov 2023 10:33:46 +0100, Tomas Hajny via fpc-pascal
>  wrote:
>
> >On November 21, 2023 8:33:55 +0100, Bo Berglund via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >>I did not know that there is a library of seed compilers available on
> >>Sourceforge, I thought everything had moved over to GitLab nowadays, so
> where
> >>exactly can I find a binary download for PiOS 64 bit on SF?
> >>Where I have looked I only find old stuff like from 2021...
> >>
> >>https://sourceforge.net/projects/freepascal/files/Linux/3.2.2/
> >>Here are tarballs that by the size seem to contain a lot of stuff apart
> from the
> >>compiler itself.
> >
> >Yes, there are full official releases provided by the FPC team and used
> by many FPC users.
> >
>
> I tried downloading one of the ones on SF and it contains a maze of other
> tar
> file with yet other tar files etc inside.
>
> I failed to locate the actual compiler executable file anywhere, so I gave
> up on
> that
>

Why do you need to make things more complicated than necessary? Extract the
tar you downloaded and execute the install script located there. Anything
else leaves the approach I have tested and confirmed to work for you.

For a successful compilation a *complete* release is necessary anyway
(well, you can deselect the documentation and demoes during the
installation :P).

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TPath enhancements (Issue #40513): can somebody test with Delphi 12?

[Sven Barth via fpc-pascal]

Bart via fpc-pascal  schrieb am Sa., 18.
Nov. 2023, 18:24:

> 1. The docs state that an exception is raised if the given paths
> contain invalid characters. Does the vlaue of the ValidateParams have
> any influence on this?
>

Also: does this depend on the operating system and/or file system? Cause
Linux file systems have different invalid characters (usually only slash
and NUL) than NTFS or FAT.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Cannot build fpc on Raspberry Pi4B running PiOS 64 bit (aarch64 Linux)

[Sven Barth via fpc-pascal]

Bo Berglund via fpc-pascal  schrieb am
Sa., 18. Nov. 2023, 11:32:

> Today after realizing that I did the following on an RPi4B where I have
> used apt
> to install the fpc compiler so I could use that as the seed compiuler to
> build
> from sources.
>

Why don't you simply follow what I DID? First of deinstall that apt fpc
again. Then download 3.2.2 for aarch64-linux from SourceForge, install it
and add /path/to/where/you/installed/fpc/bin to your PATH (using "export
PATH=/new/path:$PATH").
Best pick in an installation path like /wherever/fpc/ and select
"yes" when asked whether to adjust the fpc.cfg with $fpcversion, that will
come in handy later.

Next download the sources for 3.2.3 and extract them somewhere different
than "/wherever/fpc". Change into that directory and execute the commands
as I had written in my previous mail (you should be in the same command
line session where you adjusted PATH for this to work otherwise you need to
set it again). The INSTALL_PREFIX should be "/wherever/fpc/3.2.3".

Next set your PATH again, but this time use the directory for 3.2.3 ("echo
$PATH" plus selecting and pasting is your friend here, cause you don't want
to *extend* your path, but replace it; or simply start a new console
windows and append the path there now that I think about it ).

Now you should have a working FPC and you can compile Lazarus from source
(sorry, don't know how to setup fpcupdeluxe to use an existing compiler,
cause I don't use it).

In Lazarus you then also need to set the path to your compiler.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Cannot build fpc on Raspberry Pi4B running PiOS 64 bit (aarch64 Linux)

[Sven Barth via fpc-pascal]

Bo Berglund via fpc-pascal  schrieb am
Do., 16. Nov. 2023, 08:19:

> From the Lazarus list:
>
> >Just a quick follow-up here:
> >It seems like the fpc sources have not been updated with the solution to
> the bug
> >discussed here:
> >
> >https://gitlab.com/freepascal.org/fpc/source/-/issues/39295
> >
> >This causes the build of Lazarus using fpcupdeluxe with the latest fpc
> 3.2.2 to
> >fail because of a problem with __libc_csu_init during linking.
> >
> >Apparently it is fixed in non-released sources of fpc which we are waiting
> >for...
>
> The GitLab ticket was opened 2 years ago:
> https://gitlab.com/freepascal.org/fpc/source/-/issues/39295
>
> According to a post on the Lazarus forum the fix that solves the fatal
> error
> during fpc build on 64 bit aarch64 Linux (like on Raspberry Pi4B with
> Pi-OS 64
> bit) has *not* been ported to the target aarch64 Linux, only to powerpc.
>
>
> https://forum.lazarus.freepascal.org/index.php/topic,34645.msg496883.html#msg496883


Wrong. Who said that the solution consisted only of a single commit?


>
> So I am sitting here unable to run Lazarus/FPC on the RPi4B with the
> latest 64
> bit Pi-OS...
>
> Is any solution to this problem in the works?
> I have tried every fpc source release from 3.2.2 up to trunk with the
> exact same
> result (here from a build try on trunk):
>
> /bin/ld:
> /home/bosse/devtools/lazarus/2.2.6/fpcsrc/rtl/units/aarch64-linux/cprt0.o:
> in
> function `_start':
> (.text+0x54): undefined reference to `__libc_csu_init'
> /bin/ld: (.text+0x58): undefined reference to `__libc_csu_init'
> /bin/ld: (.text+0x5c): undefined reference to `__libc_csu_fini'
> /bin/ld: (.text+0x60): undefined reference to `__libc_csu_fini'
> make[1]: *** [Makefile:2682: packages_smart] Error 2
> make: *** [Makefile:2837: build-stamp.aarch64-linux] Error 2
> fpmake.pp(60) Error: Error while linking
> fpmake.pp(60) Fatal: There were 1 errors compiling module, stopping
> Fatal: Compilation aborted
>
> I believe that a lot of people will experience this since the 64 bit OS on
> RPi4
> has been recently released as the *recommended* version on that popular
> platform...
>

I can not reproduce. On a Raspberry OS 10 64-bit I downloaded FPC 3.2.2 for
aarch64-linux from SourceForge as well as the sources of both 3.2.3 and
3.3.1 from GitLab.
I install 3.2.2, setup PATH to find the compiler and simply do the
following for each 3.2.3 and 3.3.1 (in their corresponding source
directories):

make all FPMAKEOPT="-T 4" -j 4
make install INSTALL_PREFIX=/path/for/fpc/ - j 4
cd /path/for/fpc//bin
ln -s .. /lib/fpc//ppca64 ppca64

(the -T and -j are simply for parallel compilation)

Both 3.2.3 and 3.3.1 (don't forget to set PATH correctly!) can successfully
compile a hello world program that links against the C library (in my case
by using the cthreads unit) while 3.2.2 can not (as expected).

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Incompatible procedure types

[Sven Barth via fpc-pascal]

Hairy Pixels  schrieb am Do., 9. Nov. 2023, 01:37:

>
>
> > On Nov 8, 2023, at 1:50 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > Please provide example code so that one can look at it. Such messages
> without example are more often than not simply useless.
> >
>
> So this ended up being because I didn't enable the "nestedprocvars" mode
> switch and you get that error assigning to a "is nested" procedure
> variable. This has bitten me so many times. That error message is
> basically worthless to a user and should probably be changed.
>

Still, provide an example, please.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Incompatible procedure types

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Mi., 8. Nov. 2023, 01:48:

> What does this error mean? It's comparing a pointer to a procedure to a
> procedure variable (a callback). The signature appears exactly the same
> "function(TSymbol;TSymbol):LongInt is nested" so what's the problem?
>
> error: Incompatible type for arg no. 2: Got " function(TSymbol;TSymbol):LongInt is nested;StdCall>", expected
> "TSList$1$crcCC4DE170_crc9A33B934. function(TSymbol;TSymbol):LongInt is nested;StdCall>"
>

Please provide example code so that one can look at it. Such messages
without example are more often than not simply useless.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Creating capturers

[Sven Barth via fpc-pascal]

Hairy Pixels  schrieb am Sa., 4. Nov. 2023, 15:48:

>
>
> > On Nov 4, 2023, at 4:22 PM, Sven Barth 
> wrote:
> >
> > Then don't assign them every "frame". If you just keep them around then
> they aren't more expensive than a virtual method call.
> > And any other mechanism would involve the heap as well, because that's
> how anonymous functions that capture variables work and thus anything that
> wants to store them must play by the same rules. There won't be any changes
> there.
> >
>
> The need for a universal function pointer type really isn't about the
> function references even though they work for that, albeit with unneeded
> overhead.
>
> Lets say you have a sort function which takes a compare callback
> parameter. You can make the callback type "is nested" which works on global
> and nested/anonymous functions but not methods. What if the user wants to
> provide the compare function as a method because they're calling it in a
> class which shares the code elsewhere? As the writer of the function you'd
> need to make 2 versions of the function, one "is nested" and "of object".
>
> The writer of the sort function shouldn't need to know what kind of
> function it will be passed, just that a comparison callback is provided,
> right?
>

Then you simply make the callback function type a function reference and be
done. The user can pass in any kind of function they want and *nearly*
every type of function-like pointer.

And if you're really worried about performance when providing such a class
then simply provide overloads woth different function-like pointer types,
the compiler will pick the most suitable one then.

It's really not that hard as an implementer of a class.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Compiler probem?

[Sven Barth via fpc-pascal]

Paul Renaud via fpc-pascal  schrieb am
Sa., 4. Nov. 2023, 16:18:

> Hi, I have a question about some code.
>
> The following code segment generated a compiler error when I compiled it
> with...
>
> fpc Sample -Se -gl -al
>
> but not when it's compiled with...
>
> fpc Sample -Se -gl
>
> ...
> Asm
>   LdRH R0, [ R1, R2, LSL #1 ]
> End [ 'R0',  'R1' ];
> ...
>
> Any idea why?  Its driving me crazy.
>

Please provide information what target your compiling for, what target you
are compiling from, the compiler version you are using, the exact error you
get and a complete code example.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Creating capturers

[Sven Barth via fpc-pascal]

Hairy Pixels  schrieb am Sa., 4. Nov. 2023, 01:42:

>
>
> > On Nov 3, 2023, at 8:31 PM, Sven Barth 
> wrote:
> >
> > If you need a catch all type, then you should use function references.
> There is no need to invent yet another type.
> > The only thing it can not handle is the assignment of nested function
> pointers (in contrast to nested functions directly), because they can only
> ever be used in a function that is below the one where the nested function
> was assigned which is not a guaranteed property for function references.
> >
>
> not always because it creates a heap allocated interfaces for every
> function they're used in, even if it doesn't escape the scope. Maybe this
> was fine for Delphi but they can't be used for anything real time outside
> of GUI apps.
>

Then don't assign them every "frame". If you just keep them around then
they aren't more expensive than a virtual method call.
And any other mechanism would involve the heap as well, because that's how
anonymous functions that capture variables work and thus anything that
wants to store them must play by the same rules. There won't be any changes
there.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Creating capturers

[Sven Barth via fpc-pascal]

Hairy Pixels  schrieb am Fr., 3. Nov. 2023, 12:37:

>
>
> > On Nov 3, 2023, at 2:08 PM, Sven Barth 
> wrote:
> >
> > By default the purpose of anonymous functions assigned to function
> references *is* that they can escape their scope. This will not change,
> because they were after all introduced for Delphi-compatibility and there
> won't be any designations that the value can't escape. If the compiler
> can't figure it out by its own (see above) then tough luck; use a feature
> better suited for that.
> >
>
> Ok I misinterpreted what you previously said then.
>
> I think Swift does this because they only have a single function pointer
> type which serves all purposes while FPC has 4 distinct types.
>
> IMO FPC needs this also since it's not possible for libraries to know
> which kind of function the caller may provide. Behind the scenes the
> different types are required (global, nested, method, reference) but there
> should be a way to unify these into single type. How to store the capturer
> and manage its memory would be an open question though.
>

If you need a catch all type, then you should use function references.
There is no need to invent yet another type.
The only thing it can not handle is the assignment of nested function
pointers (in contrast to nested functions directly), because they can only
ever be used in a function that is below the one where the nested function
was assigned which is not a guaranteed property for function references.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Creating capturers

[Sven Barth via fpc-pascal]

Hairy Pixels  schrieb am Fr., 3. Nov. 2023, 02:00:

>
>
> > On Nov 2, 2023, at 1:44 PM, Sven Barth 
> wrote:
> >
> > Now for nested as well as anonymous routines the compiler determines
> whether a capturer is required at the point that the nested or anonymous
> routine is assigned to a function reference (cause otherwise it can be
> handled as a nested function or even a function or method pointer). This
> requirement is detected during the parsing of the routine.
>
> On second thought I had some questions about this part. From what I see
> FPC always allocates the interface when reference pointers are used but
> what you write suggests maybe the compiler will demote the type to
> something more optimized (like a nested function). We talked about this at
> length before but I don't think anything was decided yet.
>
> for example:
>
> procedure DoThis;
> var
>   proc: reference to procedure;
> begin
>   proc := procedure
>   begin
>   end;
>   proc();
> end;
>
> doesn't need the heap allocated instance because the function reference
> never escapes the scope and it has no captured variables so it could be
> demoted to a global function even of nested.
>

As soon as an anonymous function gets assigned to a function reference it
*must* be converted to a method of the capturer and an interface to that
must be assigned to the function reference. Because that's what function
references are: interfaces.

If you don't want that then call the anonymous function directly without
assigning it to anything or assign it to a nested function pointer and call
that.

In *theory* the compiler could detect that "proc" doesn't leave the scope
and that it's value is "constant" (namely a function) and thus could
optimize that, but that requires quite some improvements to the optimizer.


> In fact Swift requires you to mark closures types as "@escaping" if they
> can escape the current scope so that the compiler can be optimize them.
> This is the feature I was thinking FPC needs.
>

By default the purpose of anonymous functions assigned to function
references *is* that they can escape their scope. This will not change,
because they were after all introduced for Delphi-compatibility and there
won't be any designations that the value can't escape. If the compiler
can't figure it out by its own (see above) then tough luck; use a feature
better suited for that.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Creating capturers

[Sven Barth via fpc-pascal]

Am 01.11.2023 um 06:18 schrieb Hairy Pixels via fpc-pascal:

I'm curious how the capturer is created in the case of anonymous functions. I 
know the function needs to create a capturer when nested functions are declared 
but what happens if there is an anonymous function which is declared in the 
code section?

I think the compiler will only know about the requirement to create a capturer 
at this point but local variables have already been assigned so do they need to 
do an extra copy to the capturer when it's created?

With nested function this is not a problem since the capturer can be created 
before any locals are assigned and thus not copying is needed, if I understand 
correctly.


The most important piece of knowledge is that in a routine with nested 
(or anonymous) routines the nested (or anonymous) routines aren't 
compiled down to machine code right away. The compiler first parses the 
whole hierarchy until it's on the global/method level again and only 
*then* it compiles the outermost routine followed by the nested ones.


Now for nested as well as anonymous routines the compiler determines 
whether a capturer is required at the point that the nested or anonymous 
routine is assigned to a function reference (cause otherwise it can be 
handled as a nested function or even a function or method pointer). This 
requirement is detected during the parsing of the routine.


If the routine requires a capturer then after the whole hierarchy has 
been parsed, then all the captured variables will be moved from the 
local symtable of the routine to the capturer or corresponding capture 
variables for parameters will be introduced and then the whole nodetree 
will be walked to adjust usages of the involved symbols.


So, no, there is no copy involved (except for parameter values right at 
the start of a routine where a parameter is captured) as the whole 
variables are relocated into the capturer and they're only ever accessed 
from there.


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] operator := in mode delphi?

[Sven Barth via fpc-pascal]

Martin Frb via fpc-pascal  schrieb am Mi.,
25. Okt. 2023, 21:38:

> Thanks, but that isn't the part of the answer I was looking for
>
> I was looking for a global operaton :=
>
> That could be used for an array (rather than just record/class).
>
> But according to the docs that I found that is not possible
>

Correct.

Delphi does not support global operator overloads and not every feature
that is available in FPC is made available in mode Delphi the main purpose
of which is to compile Delphi code after all.

Regards,
Sven

On 24/10/2023 23:51, Sven Barth via fpc-pascal wrote:
>
> Martin Frb via fpc-pascal  schrieb am
> Di., 24. Okt. 2023, 23:30:
>
>> Is there a modeswitch to enable it?
>>
>>
>> Because currently I am getting an error in mode delphi.
>>
>
> In mode Delphi it's called "Implicit" as Delphi does not support symbolic
> operator overloads.
>
> Regards,
> Sven
>
>>
> ___
> fpc-pascal maillist  -  
> fpc-pascal@lists.freepascal.orghttps://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] operator := in mode delphi?

[Sven Barth via fpc-pascal]

Martin Frb via fpc-pascal  schrieb am Di.,
24. Okt. 2023, 23:30:

> Is there a modeswitch to enable it?
>
>
> Because currently I am getting an error in mode delphi.
>

In mode Delphi it's called "Implicit" as Delphi does not support symbolic
operator overloads.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Error: compilation raised exception internally

[Sven Barth via fpc-pascal]

Thomas Kurz via fpc-pascal  schrieb am
Sa., 21. Okt. 2023, 19:22:

> > An exception or an internal error during compilation should *always* be
> > reported.
> > Please also provide a minimal, self contained example that shows the
> > problem.
>
> This is not always trivial because the internal errors are sometimes quite
> fiddly. I have a project in which an internal error occurs sometimes. When
> I do a "cleanup and build" (in Lazarus), it works well. There seems to be
> an influence of the order in which units are compiled, because I can change
> code in many places without getting the internal error again. But when I
> change code in other units, I get the internal error, but it's clearly
> uncorrelated to the line at which it occurs.
>

Without a way to reproduce and debug the issue it's very unlikely to get
solved especially if it's a problem that only occurs in very specific
circumstances.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Error: compilation raised exception internally

[Sven Barth via fpc-pascal]

Rafael Picanço via fpc-pascal  schrieb am
Sa., 21. Okt. 2023, 02:50:

> Hi everyone,
>
> I am getting a strange error when compiling a project. I am really not
> sure what is going on, because it occurs sometimes, consistently in some
> lines of the code with calls to this static variable:
> ...
> function NextID(ID : word) : word;
> ...
> NextID(ContainerClass.SomeTypeInstance.ID)
> ...
> type
>   TSomeType = class(TSomeBaseClass)
>   public
> ID : TTrialID; static;
>   end;
>
> I hit F9 again and then the project compiles with error.
>
> Any suggestions? Should I care about this error and report it??
>

An exception or an internal error during compilation should *always* be
reported.
Please also provide a minimal, self contained example that shows the
problem.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] All methods vitrual ?

[Sven Barth via fpc-pascal]

Adriaan van Os via fpc-pascal  schrieb am
Mo., 16. Okt. 2023, 15:14:

>
> > That's absurd, there are many features in modes objfpc and macpas
> > that don't compile with Delphi.
> >
> >
> > That doesn't make it any less true.
> >
> > Also we won't add it anyway, so... 路‍♀️
>
> Apperently, a sensible discussion, based on logical arguments, instead of
> dogma, is impossible.
>

To quote our FAQ at https://www.freepascal.org/faq.html with the entry
"There is a new language extension that would be really useful. Will you
include it?" at point 2:

"The extension must have real value. Anything that is only a shorter
notation does not apply, unless it is out of compatibility with an existing
Pascal/Delphi codebase. Practically it means it must make something
possible that cannot be done otherwise or be a compatibility item"

Your suggestion fails that as it is merely syntactic sugar for something
you can accomplish using existing mechanisms even if it might be more
involved.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] All methods vitrual ?

[Sven Barth via fpc-pascal]

Adriaan van Os via fpc-pascal  schrieb am
So., 15. Okt. 2023, 08:54:

> Sven Barth via fpc-pascal wrote:
> > There will be no new visibility specifiers for something like this.
> >
> > And yes, it affects compatibility, as that means that code using that
> > feature couldn't be compiled with Delphi and especially for library
> > developers that might be an important point.
>
> That's absurd, there are many features in modes objfpc and macpas that
> don't compile with Delphi.
>

That doesn't make it any less true.

Also we won't add it anyway, so... 路‍♀️

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] free pascal compiler on Linux Red Hat for target motorola 68k

[Sven Barth via fpc-pascal]

LECUYER Philippe via fpc-pascal  schrieb
am Sa., 14. Okt. 2023, 15:16:

> Hi,
>
> I search a free pascal cross compiler (for host Linux Red hat 7.x and
> target Motorola 68k)
>
> I test the last 3.2.2 version but I doesn’t find the option for target
> Motorola 68k (fpc –help)
>
> It’s run when I compile an example (in examples directory) and execute on
> Linux RH 7.x but I want to produce the binary for 68k target.
>
> Thanks for helping me.
>

You need to build a suitable compiler. For this you download the source
(either 3.2.2 or the development version 3.3.1) and do a make:

make all CPU_TARGET=m68k OS_TARGET=linux BINUTILSPREFIX=
FPMAKEOPT="-T " - j 

Where  is the prefix of the binutils for 68k (as and ld, e.g.
m68k-linux-gnu-) and  is the number of CPU cores you have.

After that you do a

make install CPU_TARGET=m68k OS_TARGET=linux BINUTILSPREFIX=
INSTALL_PREFIX=/path/to/the/destination

Depending on the destination path you need to do that as root.

There are further details, but I can't describe them right now, so don't
hesitate to ask if you have issues.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] All methods vitrual ?

[Sven Barth via fpc-pascal]

Adriaan van Os via fpc-pascal  schrieb am
Fr., 13. Okt. 2023, 11:02:

> Michael Van Canneyt via fpc-pascal wrote:
> >
> >
> > On Wed, 11 Oct 2023, Adriaan van Os via fpc-pascal wrote:
> >
> >> Michael Van Canneyt via fpc-pascal wrote:
> >>
> >>> $M controls the inclusion of RTTI, i.e. it allows or disallows the
> >>> use of the published section.
> >>> No more, no less.
> >>
> >> I don't see any use in allowing or disallowing something. And with the
> >> current design, it is, as I said, impossible, without macros, to
> >> compile the same code with {$M+} and {$M-}.
> >
> > While I agree with your statement about allowing/disallowing use of
> > 'published' based on a directive, we inherited this from Delphi and it
> > is a very basic part of the language & RTL, so changing it is simply not
> > an option.
>
> Well, as I said, adding a new visibility specifier, e.g. "visible",
> meaning "public" in {$M-} state
> and "published" in {$M=}", does in no way degrade compatibility with
> Delphi code. One could reserve
> the new visibility specifier for modes objfpc and macpas.
>

There will be no new visibility specifiers for something like this.

And yes, it affects compatibility, as that means that code using that
feature couldn't be compiled with Delphi and especially for library
developers that might be an important point.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] All methods vitrual ?

[Sven Barth via fpc-pascal]

Adriaan van Os via fpc-pascal  schrieb am
Mi., 11. Okt. 2023, 06:25:

> Sven Barth via fpc-pascal wrote:
> > Am 10.10.2023 um 11:18 schrieb Adriaan van Os via fpc-pascal:
> >>
> >>>
> >>> - In the released compiler, if you remove all visibility specifiers,
> >>> you can
> >>>   get a list by specifying {$M+} on your base object and then list all
> >>>   published methods using the RTTI.
> >>
> >> My understanding is that I have to explicitely specify public for
> >> class fields, otherwise the compiler will issue an error.
> >
> > What exactly do you mean here? Do you have an example?
>
> {$mode macpas}
> {$M+}
> program testrtti;
> type
>T = object( TObject)
>  i: integer;
>  procedure A;
>end;
> procedure T.A;
>begin end;
> begin
> end.
>
> Free Pascal Compiler version 3.0.4 [2018/09/30] for x86_64
> Copyright (c) 1993-2017 by Florian Klaempfl and others
> Target OS: Darwin for x86_64
> Compiling testrtti.pas
> testrtti.pas(6,5) Error: Symbol cannot be published, can be only a class
> testrtti.pas(13) Fatal: There were 1 errors compiling module, stopping
>

Ah, yes, only classes and interfaces can be used for published fields. For
properties anything is allowed.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] All methods vitrual ?

[Sven Barth via fpc-pascal]

Am 10.10.2023 um 11:18 schrieb Adriaan van Os via fpc-pascal:




- In the released compiler, if you remove all visibility specifiers, 
you can

  get a list by specifying {$M+} on your base object and then list all
  published methods using the RTTI.


My understanding is that I have to explicitely specify public for 
class fields, otherwise the compiler will issue an error.


What exactly do you mean here? Do you have an example?

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] All methods vitrual ?

[Sven Barth via fpc-pascal]

Am 10.10.2023 um 11:01 schrieb Adriaan van Os via fpc-pascal:

Sven Barth via fpc-pascal wrote:

No. Only those in the published section are part of the vMethodTable. 
And when compiled with $M+ the default visibility is changed from 
public to published. 


Also, I can get a list of the interfaces inherited from by a class, by 
looking at the vIntfTable of the VMT of the class. But is there also a 
way to get the method names from a CORBA interface ?


CORBA or raw interfaces don't have RTTI generation enabled. And even 
then the (COM) interfaces also need to have been parsed with $M enabled.


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] All methods vitrual ?

[Sven Barth via fpc-pascal]

Am 10.10.2023 um 02:04 schrieb Adriaan van Os via fpc-pascal:

Sven Barth via fpc-pascal wrote:

No. Only those in the published section are part of the vMethodTable. 
And when compiled with $M+ the default visibility is changed from 
public to published. 


OK, but that means that by explicitely specifying 
public/private/protected for fields and published for methods, a 
method list can be generated when compiling with {$M+}.


Only for the class that is parsed while $M is enabled and all that 
inherit from that class. It does not affect any parent classes that 
don't have $M enabled.


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] All methods vitrual ?

[Sven Barth via fpc-pascal]

Adriaan van Os via fpc-pascal  schrieb am
Mo., 9. Okt. 2023, 15:44:

> > Is there a trick to make (in mode macpas) all class methods implicitely
> virtual ? I mean, without
> > adding the virtual keyword to all of them ? The reason is that I want to
> create a tree view of the
> > class hierarchy with all the method names (not just those that are
> normally in the VMT because they
> > are overridden).
>
> Hm, looking somewhat further, it seems that the vMethodTable of the class
> VMT does list all
> methods, not just the virtual methods, provided the code was compiled with
> type info {$M+}
>
> is that correct ?
>

No. Only those in the published section are part of the vMethodTable. And
when compiled with $M+ the default visibility is changed from public to
published.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] All methods vitrual ?

[Sven Barth via fpc-pascal]

Adriaan van Os via fpc-pascal  schrieb am
Mo., 9. Okt. 2023, 14:29:

> Is there a trick to make (in mode macpas) all class methods implicitely
> virtual ? I mean, without
> adding the virtual keyword to all of them ? The reason is that I want to
> create a tree view of the
> class hierarchy with all the method names (not just those that are
> normally in the VMT because they
> are overridden).
>

No, there is no such way.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Barriers semantics

[Sven Barth via fpc-pascal]

Jonas Maebe via fpc-pascal  schrieb am
Mo., 14. Aug. 2023, 21:02:

> On 14/08/2023 18:19, denisgolovan via fpc-pascal wrote:
> > Now we have "volatile" intrinsic for assignments in place, I'd like to
> ask for another clarification.
>
> Just to make sure given your questions below: using volatile in the
> context of multithreaded code is completely wrong in 99.9% of the cases,
> and when it's not in the best case it's usually just highly inefficient.
> volatile in FPC/C++ is unrelated to volatile in Java or C# in that respect.
>
> > Documentation states we have following barriers - ReadBarrier,
> WriteBarrier, ReadDependencyBarrier, ReadWriteBarrier.
> >
> > I'd like to get an idea how those related to more common / standard
> terms - Acquire/Release & their combinations?
>
> Read/Write barriers are terms used in cpu architecture manuals.
> Acquire/Release are high level parallel programming terms.
>

Doesn't Aarch64 use acquire/release instructions for locking? 樂


> > Is it safe to assume that:
> >
> > ReadBarrier - Acquire
> > WriteBarrier - Release
> > ReadWriteBarrier - Acquire+Release
> > ReadDependencyBarrier - which one is that?
>
> You cannot express a ReadDependencyBarrier in terms of acquire/release.
> See e.g. the explanation of "data dependency barrier" at
> https://www.sobyte.net/post/2022-08/cpu-cache-and-memory-barriers/ . In
> practice, I don't think any currently used cpu architectures still
> require such barriers though.
>

It depends on the use case. When working with external hardware onm Aarch64
(e.g. with DMA) they are very much a necessity.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Pointer question

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Do., 10. Aug. 2023, 18:30:

>
>
> > On Aug 10, 2023, at 5:43 AM, Bernd Oppolzer via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > PTRADD (p, i) - p is type ANYPTR, i is integer, result is of type ANYPTR
> > PTRDIFF (p1, p2) - two pointers, the result is integer
> > ANYPTR is a predefined type, compatible with every (typed pointer)
> > ADDR (x) is a function (borrowed from PL/1), which returns an ANYPTR ...
> and it is allowed for all types of variables
> > PTRCAST is the same as PTRADD (p, 0) - and is used to cast pointers
> between incompatible pointers (not type safe)
> >
>
> Not a bad idea to clarify this. Besides p + 1 the pointer math operators
> are difficult to understand and feel antiquated.
>

Then you simply aren't using them often enough. E.g. the RTTI internal code
is full of them and additional typecasts would simply muddle up otherwise
relatively clear code.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Pointer question

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Mi., 9. Aug. 2023, 04:59:

> I just noticed this by accident and I don't understand. Why does " x :=
> @r; " compile? I would expect it to fail like the next line where I cast to
> the explicit type.
>
> type
>   TMyRec = record end;
>   PMyRec = ^TMyRec;
> var
>   x: PByte;
>   r: TMyRec;
> begin
>   x := @r;// works
>   x := PMyRec(@r);  // fails
> end.


By default @ returns a *untyped* pointer that can be assigned to any
pointer type. Thus is compatible with Delphi and can be controlled with the
$TypedAddress directive (there's a slight exception to this when you assign
a pointer to a function to a function variable (etc) or pass it to such a
parameter, because the compiler has to pick the correct overload if there
are multiple functions with the same name in scope).

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] $IMPLICITEXCEPTIONS vs early function return

[Sven Barth via fpc-pascal]

Am 14.07.2023 um 18:41 schrieb Hairy Pixels via fpc-pascal:

Question is, how is this different from early function returns? Does the 
compiler still need to wrap the whole function body in try..finally to capture 
any places the function could return?


There is no difference between early return or not, because if the early 
return isn't taken any other path needs to be protected as well. Thus 
the whole function is wrapped which deals with all of that - and also 
simplifies the implementation.


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] 3123 inherited not supported inside inline

[Sven Barth via fpc-pascal]

Mattias Gaertner via fpc-pascal  schrieb
am Sa., 24. Juni 2023, 13:12:

> Hi,
>
> With development fpc I get a lot of messages like:
>
> fgl.pp(1112,1) Note: (3123) "inherited" not yet supported inside inline
> procedure/function
>
> Since most users can't do anything about the fgl inline modifier, this
> message dilutes the output.
>
> IMO such a message should be off by default.
>
> What do you think?
>

They are a reminder for us devs that these need to be fixed in the long
term. If the messages are off by default *no one* will care about them.
This way I least am reminded regularly that I want to give fixing them a
try.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] 3123 inherited not supported inside inline

[Sven Barth via fpc-pascal]

Michael Van Canneyt via fpc-pascal 
schrieb am Sa., 24. Juni 2023, 14:18:

>
>
> On Sat, 24 Jun 2023, Mattias Gaertner via fpc-pascal wrote:
>
> > Hi,
> >
> > With development fpc I get a lot of messages like:
> >
> > fgl.pp(1112,1) Note: (3123) "inherited" not yet supported inside inline
> > procedure/function
> >
> > Since most users can't do anything about the fgl inline modifier, this
> > message dilutes the output.
> >
> > IMO such a message should be off by default.
> >
> > What do you think?
>
> The simplest solution is to remove the inline modifier, since it is clearly
> superfluous for that routine.
>
> According to Florian, inline should not be used to begin with, since the
> compiler should be able to decide autonomously to inline a routine or not.
>

I don't agree with Florian here cause the compiler detecting an inlineable
routine that's declared in the interface section means an interface change
after the interface section was already parsed and thus leading to the
necessity to do recompilations which are already not working that well.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Legitimate use of for and break

[Sven Barth via fpc-pascal]

Am 18.06.2023 um 19:28 schrieb Travis Siegel via fpc-pascal:


On 6/18/2023 1:04 AM, Hairy Pixels via fpc-pascal wrote:
I don't remember break NOT being in Pascal. How did you exit a loop 
otherwise, goto? Break is common in basically all languages now. 
Can't think of a language I've used without it.


Use a variable, set the variable when you hit an exit criteria, then 
before repeating the loop, check the variable, if it's true, exit the 
loop (exit does this), or just craft the loop (easy to do if it's a 
loop until construct) so it exits the loop automatically.  Probably 
not as efficient as break, but since I didn't know it was a valid 
command, 


“Exit” leaves the surrounding *function*, not the surrounding *loop*.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Non-initialized member access warning

[Sven Barth via fpc-pascal]

Am 07.06.2023 um 10:44 schrieb Hairy Pixels via fpc-pascal:

I'm curious, why doesn't the following code give a warning? Shouldn't the compiler know 
you're assigning to "r" which hasn't been initialized yet?

type
TMyClass = class
x: integer;
end;

procedure MyProcedure;
var
r: TMyClass;
begin
r.x := 1;
end;


Please report a bug with a complete example.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Error: Argument cannot be assigned to

[Sven Barth via fpc-pascal]

Martin Frb via fpc-pascal  schrieb am So.,
4. Juni 2023, 18:10:

> On 04/06/2023 17:49, Martin via fpc-pascal wrote:
> > On 04/06/2023 15:04, Juha Manninen via fpc-pascal wrote:
> >> Why the following code fails to compile?
> >> MyObj.RecInstance.ii := 123;
> > Technically you can modify the members of the temp record (just to
> > have the work thrown away afterwards).
> >
> > So I guess the compiler forbids it, because the only case it would
> > ever be done is: by mistake.
>
> Btw, this works (or actually not, it works wrong)
>
>with  MyObj.RecInstance do {begin} ii := 123; {end;}
>
> Now you could do some work with the temp result, and have it trashed at
> the end of the "with" block.
>
> However, fpc incorrectly changes the value in the original record.
> Yet, don't use it. It will (likely) change, and stop working. (or work
> correctly, changing the temp value only).
>

Correct. This *will* be fixed also. There already is a bug report about it.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Make a distinct pointer type

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Do., 1. Juni 2023, 03:16:

>
>
> > On May 31, 2023, at 9:20 PM, Michael Van Canneyt via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > Type aliases are always assignment compatible.
>
> btw, what does the "type" prefix do then? I thought that made them
> non-aliases or distinct types.
>

It only makes a difference for the RTTI as well as overloading.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Freeing memory with exceptions

[Sven Barth via fpc-pascal]

Steve Litt via fpc-pascal  schrieb am Di.,
30. Mai 2023, 21:57:

> I don't know about other operating systems, but on Linux a crashed
> program gives up all its memory, even leaked memory, upon termination,
> so I'm not sure why this attention to memory leak on abnormal
> termination is even necessary.
>

An exception does not have to end with the program's termination. And if
the program does not terminate due to an exception it makes sense to avoid
memory leaks as the program might be long running.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Compile time -> processor benchmark values

[Sven Barth via fpc-pascal]

Am 29.05.2023 um 15:23 schrieb Rainer Stratmann via fpc-pascal:

Now I have a i7-3770S

cpubenchmark says:
Average CPU Mark: 6175
Single Thread Rating: 2043
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i7-3770S+%40+3.10GHz

I expect to buy a new computer with a i5-13400F or similar
cpubenchmark says:
Average CPU Mark: 25969
Single Thread Rating: 3702
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i5-13400

What is important for the compile time?
The average CPU Mark that means more than 4 times faster?
Or the single thread rating that means 1,8 times faster?

Besides faster memory, ssd, etc.


FPC itself is single threaded. So for that the single thread rating is 
more important. However Lazarus (and fpmake) can parallelize the 
building of packages if they don't depend on each other. On the other 
hand this is only really important when rebuilding and not when doing 
normal builds.


So in my opinion I'd keep an eye on the single thread rating.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Freeing memory with exceptions

[Sven Barth via fpc-pascal]

Mattias Gaertner via fpc-pascal  schrieb
am Do., 25. Mai 2023, 08:23:

> On Thu, 25 May 2023 07:55:39 +0200
> Sven Barth via fpc-pascal  wrote:
>
> >[...]
> > But this is what "managed type" *means*: that the compiler and RTL
> > will make sure that it's correctly freed as long as nothing
> > unexpected happens.
>
> ... and exceptions are expected.
>

Depends on the circumstances: in code with disabled implicit exception
frames, but managed types exceptions are to be considered unexpected. But
otherwise they are indeed expected.


> Maybe better: As long as the user does not break the rules.
>

Agreed.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Freeing memory with exceptions

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Do., 25. Mai 2023, 04:32:

>
>
> > On May 24, 2023, at 8:46 PM, Michael Van Canneyt via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > I see no problem, I am used to this.
> >
> > This is Pascal, you need to manage your memory and hence your
> references, this is true even in the absence of exceptions: In your example
> you would
> > also need to remember to remove your instance from the list after you
> free
> > it, even if there are no exceptions.
>
> My example is still not good. The problem I have is that once exceptions
> are used in a program calling any function now has a side effect of
> completely exiting the calling function so you need to be paranoid and wrap
> everything in try blocks just in case. A new added burden for manual memory
> management.
>

I'd say you're over thinking things. The main part is that you protect
locally allocated memory (be it class instances or plain pointers) using
"try... finally" and make sure other memory is for example deallocated in a
destructor. If that's ensured then you can have exceptions bubble up as far
as you're comfortable. E.g. in a LCL application if an exception is raised
somewhere inside an event handler and it isn't explicitly handled there it
will in the end result in a shown error dialog. Assuming all resources
along the way were guarded by resource protection blocks life can just go
on then when the user closes the dialog.

In essence: always protect the resources and only handle an exception
explicitly if you can provide the user with a better error message than
what the exception already provides or have can give them the ability to
correct something.

Why is this better than handling errors as values like a normal function
> result?
>

This would mean that every function (and procedure) that can fail or calls
a routine that can fail would have to provide some kind of error channel
and the user would then have to check this, cluttering their code with
error checks (just look at how correctly error checked code with classic
Pascal I/O looks with all the checks for IOResult).
With exceptions you can simply concentrate on the meaty parts of your
algorithms or business logic and let the language itself deal with the
exceptional (pun intended).

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Freeing memory with exceptions

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Do., 25. Mai 2023, 04:26:

>
>
> > On May 24, 2023, at 10:11 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > You must have $H+ on and those are AnsiStrings? Why is there exception
> handling involved with AnsiString? I guess it needs this just in case an
> exception is thrown somewhere in the call stack?
> >
> > Because Ansi- and UnicodeString are managed types. *All* managed types
> managed string types, interfaces, Variants, managed records) must be
> finalized correctly even if an exception occurs.
> >
>
> That's a problem with exceptions then, they are baked into the language
> and impose a cost on all managed types now even if we use them or not. Even
> disabling the implicit stack frames (forgot what it's called) doesn't get
> around this right?
>

Disabling implicit exception frames does exactly what it says in the tin
and removes these automatically generated frames. This however opens you to
potential memory leaks if an exception occurs, so one should think twice
whether one uses this option.
Thankfully it's a local directive, so one can make this choice for every
function.

But this is what "managed type" *means*: that the compiler and RTL will
make sure that it's correctly freed as long as nothing unexpected happens.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Freeing memory with exceptions

[Sven Barth via fpc-pascal]

Benito van der Zander via fpc-pascal 
schrieb am Do., 25. Mai 2023, 00:15:

> Hi
>
>
> Then also run FPC/win32 in wine for a real comparison.
>
>
> Or perhaps against modern C++ on Linux would also be a real comparison
>

It wouldn't be, because that would compare two different languages. C++
doesn't have a concept of resource protection blocks like Object Pascal
has.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Freeing memory with exceptions

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Mi., 24. Mai 2023, 14:10:

> You must have $H+ on and those are AnsiStrings? Why is there exception
> handling involved with AnsiString? I guess it needs this just in case an
> exception is thrown somewhere in the call stack?


Because Ansi- and UnicodeString are managed types. *All* managed types
managed string types, interfaces, Variants, managed records) must be
finalized correctly even if an exception occurs.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Freeing memory with exceptions

[Sven Barth via fpc-pascal]

Benito van der Zander via fpc-pascal 
schrieb am Mi., 24. Mai 2023, 13:00:

> Hi,
>
> It is weird that your code calls setjmp? Are you using a non Windows
> platform?  Comparisons with Delphi should be done on Windows where the
> exception systems match. Apples to Apples please.
>
>
> It is FPC on Linux.
>
> And Delphi 4 on Linux (in WINE)
>

As Marco said, please compare using the same *target* platform otherwise
you're comparing apples with oranges due to different exception handling
mechanisms between Windows and Linux.


>
> Even if it wants to do the Linux nonsense, FPC could at least inline
> fpc_setjmp in fpc_pushexceptaddr to make it only one function call.
>

fpc_setjmp can not be unlined because a) it's an assembly function and b)
*relies* on being a separate function.

And fpc_pushexceptaddr not only accesses private state of the system unit,
it's also a larger function and thus inlining it would not provide any
benefit. Also combining them would not work, because they are for different
purposes.

The low level exception handling code is the way it is for reasons.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Oberon-0

[Sven Barth via fpc-pascal]

Adriaan van Os via fpc-pascal  schrieb am
Do., 20. Apr. 2023, 04:46:

> Ralf Quint via fpc-pascal wrote:
>
> > What does Oberon and Forth have to do with the FreePascal compiler? 
>
> 1. Niklaus Wirth
> 2. Strong resemblance between Oberon and Pascal
> 3. An early version of his book Compiler Construction used Pascal rather
> than Oberon
>

Still no reason that this is discussed on fpc-pascal instead of fpc-other
as the former is for *using FPC*.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] IRC channel for FreePascal support ?

[Sven Barth via fpc-pascal]

Jacob Kroon via fpc-pascal  schrieb am
Do., 13. Apr. 2023, 12:53:

> I ask the #fpc Libera.Chat IRC administrators (if they are listening
> here) to revoke channel operator status for user "Joanna".
>

I've already seen from others that Joanna has a rather dictatorship-like
approach to her moderation.

Problem is none of us other devs have a real interest anymore in IRC since
the move from freenode.

So suggested locations for support are the mailing lists and the forum.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Declaring an array as var or not in function calls?

[Sven Barth via fpc-pascal]

Bo Berglund via fpc-pascal  schrieb am
Do., 13. Apr. 2023, 07:49:

> What is the use case for "out" compared to "var" when it seemingly is
> doing the
> same thing?
> Or is it exactly this:
> With "out" you get a pristine empty variable which you have to initialize
> if
> needed (setting its length in this case)?
> And you are ensured no stale data will be part of it?
>

When the compiler finds an "out" parameter in a call it does not need to
check whether the variable you pass is has been written to. With a "var"
parameter you'll get "variable not initialized" warnings/hints instead.
It's the task of the called function then to provide a correct value for
the parameter.


> >
> >And if so, what is the rule for *when* to use var in function call
> argument
> >> lists for items that will be changed inside the called function and used
> >> afterwards
> >>
> >
> >The rule is simple: if you need to modify the parameter value itself (e.g.
> >changing a primitive type, changing a field in a record, changing an
> >array's length or data, changing the value of a class instance - but not
> >its fields!) you need to pass it as "var".
> >If it's a write only parameter you can even use "out".
>
> So "out" it is unless I need to use the existing data or append new data
> to it,
> in which case I need "var", right?
>

Correct.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Declaring an array as var or not in function calls?

[Sven Barth via fpc-pascal]

Bo Berglund via fpc-pascal  schrieb am
Mi., 12. Apr. 2023, 21:17:

> Now my question:
> 
> Since I am modifying the WArgs variable inside the BuildArgumentsArray
> function
> and using its new content afterwards in the WriteItem function I assumed
> that I
> had to use var as shown above, but I am not certain this is the case...
>

If you modify the length or the contents of a dynamic array parameter then
you need to use "var" or "out" modifiers (the later only if you don't need
the data passed in).


> It seems like it works also if I do not use the vars specification...
>

It should not. If it does it will likely be an implementation detail and
you shall not rely on it. Do you have an explicit example for this
behavior?

And if so, what is the rule for *when* to use var in function call argument
> lists for items that will be changed inside the called function and used
> afterwards
>

The rule is simple: if you need to modify the parameter value itself (e.g.
changing a primitive type, changing a field in a record, changing an
array's length or data, changing the value of a class instance - but not
its fields!) you need to pass it as "var". If it's a write only parameter
you can even use "out".

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Declaring an array as var or not in function calls?

[Sven Barth via fpc-pascal]

Giuliano Colla via fpc-pascal  schrieb am
Mi., 12. Apr. 2023, 22:54:

> Il 12/04/2023 21:17, Bo Berglund via fpc-pascal ha scritto:
>
> And if so, what is the rule for **when** to use var in function call argument
> lists for items that will be changed inside the called function and used
> afterwards?
>
> Your Wargs is defined as an open array, i.e. its length is unknown at
> compile time. Therefore the compiler cannot pass it in the subroutine call
> other than a pointer to the array. It cannot pass the array content because
> it doesn't know its length.
> In that case you may omit the var specifier.
> But if one day you change your mind, and decide to establish a size for
> your array, without var the compiler may decide to pass the full array data
> to the procedure, and therefore whatever you do in your procedure is done
> on the local copy of the array and not in the original array.
> My suggestion is to specify "var" whenever your procedure is expected to
> modify the data passed. It makes the program more readable, even if "var"
> is redundant.
>

There is *no* open array in the example given. Also even if there were
changing the length of an open array would not work...

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC ARM inline Assembler

[Sven Barth via fpc-pascal]

Vern via fpc-pascal  schrieb am Do., 6.
Apr. 2023, 19:06:

> After reading the FPC manual more closely , the correct compiler command
> is {$ASMMODE default} where* default *is the native system ... in this
> case Orange Pi arm64 and the compiler now allows accepting ARM assembler
> instructions
>

You don't need to use the $ASMMODE directive on non-x86 platforms, because
the default syntax will always be selected. Also it's always possible to
add assembly code.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC ARM inline Assembler

[Sven Barth via fpc-pascal]

Vern via fpc-pascal  schrieb am Do., 6.
Apr. 2023, 17:32:

> Does the current FPC compiler support  ARM inline assembler ?
>

Yes.


> If so what is the equivalent ARM command for {$ASMMODE intel}
>

There is none, because only one syntax is supported.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Converting old pascal written for Pascal/MT+ compiler

[Sven Barth via fpc-pascal]

Travis Siegel via fpc-pascal  schrieb am
Di., 4. Apr. 2023, 20:34:

> I'm not positive, because I've never used them, but I'm pretty sure
> variables configured as const, can't be changed once they're defined.


For typed constants that depends on the $WritableConsts directive.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Converting old pascal written for Pascal/MT+ compiler

[Sven Barth via fpc-pascal]

Tomas Hajny via fpc-pascal  schrieb am
Di., 4. Apr. 2023, 09:51:

> On 2023-04-04 09:43, Jacob Kroon wrote:
>
>
> Hi Jacob,
>
> >> You don't need to change "var" to "const" - if you want to ensure the
> >> variables to persist in between the function/procedure runs, you need
> >> to move them to the global level, i.e. outside of the
> >> functions/procedures. It is not advisable as a general practice (to
> >> keep all variables globally), because then you might e.g. access the
> >> same variable from multiple functions by mistake, but it would
> >> probably solve your issue. Obviously, you might need to solve
> >> potential conflicts if you use the same variable names in multiple
> >> functions/procedures (e.g. by prepending the function/procedure name
> >> to the variable name or something like that).
> >>
> >
> > I could move them to global scope, and add a prefix to avoid name
> > collisions, but using a "const" section seems more readable to me
> > since I don't need to add a prefix.
> >
> > The wiki page says (https://wiki.freepascal.org/Const):
> >
> > "The declaration const in a Pascal program is used to inform the
> > compiler that certain identifiers which are being declared are
> > constants, that is, they are initialized with a specific value at
> > compile time as opposed to a variable which is initialized at run
> > time.
> >
> > However, the default setting in Free Pascal is to allow const
> > identifiers to be re-assigned to."
> >
> > Then it says there is a flag to make reassigning to a const variable
> > an error. But if I ignore that, it would seem this is just what I
> > need, since this seems to make the variable have a whole-program
> > lifetime, no ?
> >
> > What is the technical downside to using "const", or is it just cosmetic
> > ?
>
> If you read the documentation (wiki or the real documentation in
> PDF/HTML etc.) properly, you don't find there anything saying that
> constants declared locally within functions or procedures are guaranteed
> to keep their modified values across runs of that function/procedure. It
> might behave like that, but you shouldn't rely on it unless it's a const
> on a global level (and then renaming may still be needed in case of
> conflicts).
>

It *is* documented (the remark at the end):
https://www.freepascal.org/docs-html/current/ref/refse10.html#x22-210002.2

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Cache-line alignment for records

[Sven Barth via fpc-pascal]

Matias Ezequiel Vara Larsen via fpc-pascal 
schrieb am Mi., 29. März 2023, 00:27:

> Hello,
>
> On Mon, Mar 27, 2023 at 09:35:38PM +0200, Jonas Maebe via fpc-pascal wrote:
> > On 27/03/2023 21:25, denisgolovan via fpc-pascal wrote:
> >
> > > But it's still not possible to attach alignment to type itself instead
> of variable, right?
> >
> > It is possible (
> https://gitlab.com/freepascal.org/fpc/source/-/blob/main/tests/test/talignrec1.pp
> ),
> > but it is subject to the same limitations when declaring variables of
> those
> > types.
> >
>
> Thanks, this is what I was looking for, however, when the type is
> defined as an array, only the [0] element is aligned. I was expecting
> that each element in the array would be aligned.
>

No, array types are defined as never having padding between the elements.
You need to make sure that the element is appropriately sized then.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] pointer to char vs pchar

[Sven Barth via fpc-pascal]

Am 24.03.2023 um 15:04 schrieb Benito van der Zander via fpc-pascal:

why is a pointer to a char not a pchar (for type helpers)?


Because that's how helpers work in Delphi as well: The address operator 
has as a result an expression that allows the use of a helper for the 
raw Pointer type (no matter if $TypedAddress is enabled or not).


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] compiler last sources Internal error on code including generic and anonymous function

[Sven Barth via fpc-pascal]

Tomáš Horák via fpc-pascal  schrieb am
So., 26. März 2023, 20:36:

>
> Hello, from time to time I recompile fpc and lazarus from latest sources.
> After today's recompilation compiler cannot translate construction, what
> was possible to translate couple of months ago(linux 64b). Compiler gives
> internal error 2011010304 on line 96. When there is not assignment to
> Result in anonymous function, it compiles just fine. Did I miss something
> or is it worth report bug? Attached file is just an example to simulate the
> problem.
>

In general an internal error is always worth a bug report, but in this
specific case it's already been reported.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Illegal expression when redeclare typed constant

[Sven Barth via fpc-pascal]

Zamrony P. Juhara via fpc-pascal  schrieb
am So., 26. März 2023, 00:05:

> Suppose  I have
>
> unit mytest;
>
> interface
>
> const
> MY_VALUE = 1;
> MY_INT_VALUE: integer = 1;
>
> implementation
> end.
>
> and second unit
>
> unit mytest2;
>
> interface
>
> uses mytest;
>
> const
> // this is legal
> MY_VALUE = mytest.MY_VALUE;
>
> // this  causes illegal expression
> // MY_INT_VALUE = mytest.MY_INT_VALUE;
> // MY_INT_VALUE : integer = mytest.MY_INT_VALUE;
>
> implementation
> end.
>
>
> Is there workaround to redeclare typed constant in other unit so that I
> don't need to duplicate code?
>

Typed constants are essentially variables and you can't redeclare
variables.

Only way you might do that (which I do not recommend because it opens it's
own can of worms) is to declare the original variable as "public" and to
import it in the other unit using "external".

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Downloaded cross-compiler from Sourceforge - wiki incorrect?

[Sven Barth via fpc-pascal]

Bo Berglund via fpc-pascal  schrieb am
Fr., 24. März 2023, 07:38:

> On Thu, 23 Mar 2023 09:47:36 +0100, Martin Frb via fpc-pascal
>  wrote:
>
> >On 23/03/2023 09:25, Bo Berglund via fpc-pascal wrote:
> >>
> >> Then opened Lazarus 2.2.4 with my project and changed project options as
> >> follows:
> >>
> >> Compiler_Options/Config_and_Target/Target OS(-T): Win32
> >>
> >> Everything else left as-is.
> >You need to change the CPU to i386 too
> >
> OK, I thought that the current processor could be used since it can run
> both
> types of programs...
>

That has nothing to do with your current processor. This setting is the
*target* architecture and can just as well be ARM, PowerPC, AVR, etc. as
well and your processor definitely can't run those outside of emulation.
The default setting of this is whatever architecture you installed Lazarus
as: when you install 64-bit Lazarus on Windows you'll get x86_64 as default
and if you install the 32-bit one it will be the i386. And if in the future
you install a ARM64 Lazarus on a ARM64 Windows the default will be aarch64.
So if you need a different target platform than your default you have to
change that.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Converting Delphi7 code to FreePascal with interfacing to protection key?

[Sven Barth via fpc-pascal]

Bo Berglund via fpc-pascal  schrieb am
Mi., 22. März 2023, 11:18:

>
> >The object file won't be a problem for FPC on i386-win32 because it will
> be
> >a COFF file which is the default.
>
> When you say "on i386-win32" does that mean a 32 bit version of Windows as
> the
> host system for building the programs?
>

I mean a variant of FPC that targets the i386 platform together with the
compiled units for i386-win32.


> If I have fpc 3.2.2 inbstalled on Windows 10 x64 I assume it is a 64 bit
> target
> exe which will be the output, right?
>
> If that is the case will the obj file work when building the exe?
>

No.


> Is it possible to check if the obj file is of the "COFF" type?
> Note that the timestamp of the obj file is 2003-05-29...
>

You could use the objdump utility provided with FPC (call it as "objdump -x
"). If it doesn't print any errors then it's a COFF file.


> >> 2) Is there a way to translate/convert the 32 bit Windows SPROMEPS.OBJ
> >> file into
> >> a 64 bit one such that it could be used for a 64 bit fpc compiler?
> >> It is the interface to the protection key driver on the Windows
> system...
> >>
> >
> >Aside from asking the company for a 64-bit variant or reverse engineering
> >the object file, no. How large is that object file?
>
> Size = 39330 bytes
>

That mean there's quite a bit of code in there, so it isn't trivially to
reverse engineer...

>
> >> It does work for our 32 bit Delphi7 programs on Windows 10 x64, so there
> >> must be some 32<->64 bit handling in Windows maybe?
> >>
> >
> >Are you really sure there's a driver involved? When you install it is
> there
> >a driver binary for both 32- and 64-bit? Cause 64-bit Windows *can not*
> >load 32-bit drivers.
>
> THALES has supplied a dedicated driver for Windows, which we use on all s/w
> installations. It is a rather big (2945376 bytes) installer file named
> "Sentinel
> System Driver Installer 7.6.0.exe"
> So, yes I am sure it is needed, whithout it the s/w cannot read the
> protection
> key.
> The driver has changed over the years as Windows progressed and we now use
> version 7.6.0
>

Then you should ask them for a suitable 64-bit object file (I assume that
they'll provide the one for C which they probably also did for you back
then and then you might need to adjust the import unit a bit to be usable
with x86_64-win64; as long as they also provide a C header that should be
doable).

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Converting Delphi7 code to FreePascal with interfacing to protection key?

[Sven Barth via fpc-pascal]

Bo Berglund via fpc-pascal  schrieb am
Mi., 22. März 2023, 13:57:

> On Wed, 22 Mar 2023 12:33:16 +0100, Giuliano Colla via fpc-pascal
>  wrote:
>
> >Il 22/03/2023 11:18, Bo Berglund via fpc-pascal ha scritto:
> >
> >> If I have fpc 3.2.2 inbstalled on Windows 10 x64 I assume it is a 64
> bit target
> >> exe which will be the output, right?
> >If in Project Options -> Config and Target ->Target OS you specify
> >Win32, you'll get a 32 bit exe (which is what Delphi does, I presume, if
> >it links a 32 bit object).
>
> I changed target to Win32 then when I closed the dialog an error message
> popped
> up:
>
> The current FPC has no config file. It will probably miss
> some units. Check your installation of fpc.
> [OK]  [Ignore]
>
> My installation was done using a full Lazarus/FPC installer from
> SourceForge:
> lazarus-2.2.4-fpc-3.2.2-win64.exe
>
> So both Lazarus and Fpc come from the same installer and it installs an
> isolated
> environment so one can have several versions installed at the same time.
>
> What to do now?
> And what is the problem?
>

You need to download the Win32 addon for Lazarus from the same location,
install that and then set operating system to Win32 and platform to i386.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Converting Delphi7 code to FreePascal with interfacing to protection key?

[Sven Barth via fpc-pascal]

Bo Berglund via fpc-pascal  schrieb am
Di., 21. März 2023, 23:54:

> 1) How should I go about translating the above to current FreePascal
> syntax?
>
> This involves:
> { Force FAR calls }
> {$F+}
>
> {$L SPROMEPS.OBJ}  { LINK WITH THE SUPERPRO OBJECT FILE }
>

These won't be a problem. Both Delphi and FPC (for non-i8086) will skip the
$F directive as it's not necessary on 32- or 64-bit systems.

The object file won't be a problem for FPC on i386-win32 because it will be
a COFF file which is the default.


> 2) Is there a way to translate/convert the 32 bit Windows SPROMEPS.OBJ
> file into
> a 64 bit one such that it could be used for a 64 bit fpc compiler?
> It is the interface to the protection key driver on the Windows system...
>

Aside from asking the company for a 64-bit variant or reverse engineering
the object file, no. How large is that object file? Maybe it's only a
relatively simple interface to the driver...


> It does work for our 32 bit Delphi7 programs on Windows 10 x64, so there
> must be
> some 32<->64 bit handling in Windows maybe?
>

Are you really sure there's a driver involved? When you install it is there
a driver binary for both 32- and 64-bit? Cause 64-bit Windows *can not*
load 32-bit drivers.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Working with anonymous functions

[Sven Barth via fpc-pascal]

Am 10.03.2023 um 17:34 schrieb Thomas Kurz via fpc-pascal:

Dear all,

I'm testing FPC-trunk and I'm especially interested in using anonymous 
functions because they should simplify working with TThread.Synchronize and 
others a lot.

I stumbled upon an issue which I'd like to post here first because I am not 
sure whether it's a bug or just a wrong usage on my side.

Here's a small example:


program project1;

{$modeswitch anonymousfunctions}
{$modeswitch functionreferences}

uses Classes, EventLog, SysUtils;

type
   TTest = class
 FOnLog: TLogMessageEvent;
 procedure CallOnLog (AEventType: TEventType; AMessage: String);
   end;

procedure TTest.CallOnLog (AEventType: TEventType; AMessage: String);

var
   r: reference to TThreadMethod = nil;


/That/ should not compile. The correct syntax is "reference to function 
..." or "reference to procedure ...".


And the type you're looking for is "TThreadProcedure" which is declared 
as "reference to procedure".



   m: TThreadMethod = nil;

begin
   // This doesn't work because the anonymous procedure is
   // capturing local symbols. I understand that this doesn't work.
   m := procedure
 begin
   FOnLog (Self, AEventType, AMessage);
 end;

   // As far as I have understood
   // https://forum.lazarus.freepascal.org/index.php/topic,59468.0.html
   // the solution should be to use a "reference to".
   // In fact, assignment works as expected:
   r := procedure
 begin
   FOnLog (Self, AEventType, AMessage);
 end;

   // But I seem not to have any change to pass the reference.
   // Both versions fail:
   TThread.ForceQueue (NIL, r());
   TThread.ForceQueue (NIL, @r);
end;

begin
end.


As you can see, the goal is to call TThread.ForceQueue. Of course, the easiest solution 
was having an overloaded "TThread.ForceQueue (TThread, TThreadProcedure)" as is 
the case with Delphi. I have already posted a feature request on Github.


I've added the overload.



But I don't know why I can't use a "reference to TThreadMethod". If I 
understand the feature announcement correctly, this should work, shouldn't it?


That declaration is nonsense, so no, that should definitely not work.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] star operator on enum types

[Sven Barth via fpc-pascal]

Giuliano Colla via fpc-pascal  schrieb am
Do., 26. Jan. 2023, 18:43:

> I found in a fpc program a statement sort of:
> Type
>   TSomeType = (a,b,c)
>   TaType = set of TSometype
> var
>   setA,setB: TaType;
> .
> *if setA * setB = [] then doSomething*;
>
> which I found very smart to detect if the two sets have some common
> elements, but I've been unable to find in the fpc documentation how the *
> operator is overloaded in fpc when dealing with enumerated and sets of
> enumerated types. Should I find out by trial and error or it's written
> somewhere?
>

You are operating on *sets*, not enums. Thus you need to look at the
documentation about set operators:
https://www.freepascal.org/docs-html/current/ref/refsu49.html#x156-1812.8.6

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Open array in object constructor gives error

[Sven Barth via fpc-pascal]

Hairy Pixels  schrieb am Mi., 4. Jan. 2023, 14:45:

>
>
> > On Jan 4, 2023, at 8:23 PM, Sven Barth 
> wrote:
> >
> > You said in the other mail "there's a global stack", so just return
> memory from that stack.
>
> Well the stack is just a list that holds pointers to the classes now but I
> guess you can modify that so it turns a pointer to an address in a block of
> memory? I’ve not seen this kind of data type (except for an actual memory
> manager) so I would need to create it.
>

If your stack only contains a lost of pointers then it's back to the
original question from Marc: on what memory does your TMyObject.Create()
operate? Where does the memory come from you put into your stack?

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Open array in object constructor gives error

[Sven Barth via fpc-pascal]

Hairy Pixels  schrieb am Mi., 4. Jan. 2023, 13:06:

>
>
> > On Jan 4, 2023, at 2:01 PM, Sven Barth 
> wrote:
> >
> > For something like that you are better of to use Object Pascal classes
> and override their NewInstance and FreeInstance methods.
> >
>
> What do you mean exactly? You still need to allocate some memory for them
> right so what do you gain?
>

You said in the other mail "there's a global stack", so just return memory
from that stack.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Open array in object constructor gives error

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Mi., 4. Jan. 2023, 02:40:

>
>
> > On Jan 3, 2023, at 8:39 PM, Marc Weustink via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > On what instance/variable/piece of memory would your code
> "TMyObject.Create(['1', '2', '3'])" then operate ?
>
> There’s a global stack which is opened and they are stored there during
> construction.
>

For something like that you are better of to use Object Pascal classes and
override their NewInstance and FreeInstance methods.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Local Type T and generics

[Sven Barth via fpc-pascal]

Am 31.12.2022 um 14:34 schrieb Vojtěch Čihák via fpc-pascal:

Hi,
  
I have local type TTempItem, i.e. declared inside method of a generic class.

When I write:
type
      TTempItem = record
        Item: T;
        Empty: Boolean;
      end;
I got: Identifier not found "T".
  
When I write:

type
      TTempItem = record
        Item: TBaseGList.T;  //name of the class
        Empty: Boolean;
      end;
I got: Generics without  specialization cannot be used as a type for a variable
  
And finally

type TLocalT = T;
      TTempItem = record
        Item: TLocalT;
        Empty: Boolean;
      end;
^^^ this works.
  
type TLocalT = TBaseGList.T;

      TTempItem = record
        Item: TLocalT;
        Empty: Boolean;
      end;
^^^ work too.
  
Is this intended? Or known bug?


It's a bug. Please report with a full example.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Open array in object constructor gives error

[Sven Barth via fpc-pascal]

Hairy Pixels  schrieb am Di., 3. Jan. 2023, 14:07:

>
>
> > On Jan 3, 2023, at 3:12 PM, Sven Barth 
> wrote:
> >
> > But then you don't use the type name either. You simply do
> "o.Create(...)".
> >
>
> O I get it now. I didn’t realize you couldn’t create on the type. That
> breaks my entire design then. It would be great to have a modern object
> that behaved more like classes but on the stack (like C++ does).
>

In C++ you can't use polymorphism either if the class is allocated on the
stack, so TP-style objects and C++-classes behave the same here.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Open array in object constructor gives error

[Sven Barth via fpc-pascal]

Hairy Pixels  schrieb am Di., 3. Jan. 2023, 08:04:

>
>
> > On Jan 3, 2023, at 1:36 PM, Sven Barth 
> wrote:
> >
> > Objects are not classes, they don't know the Object Pascal style syntax
> for creating them, instead you need to use the syntax for objects from TP
> times:
>
> But why do you need to use New if you just want a stack allocated object?
> The constructor is called without New I thought?
>

But then you don't use the type name either. You simply do "o.Create(...)".

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Open array in object constructor gives error

[Sven Barth via fpc-pascal]

Am 31.12.2022 um 04:35 schrieb Hairy Pixels via fpc-pascal:

Why is using the open array parameter illegal using the Object type?



{$mode objfpc}

program test;

type
   TMyObject = object
 constructor Create(text: array of String);
   end;

constructor TMyObject.Create(text: array of String);
begin
end;

begin
   TMyObject.Create(['1', '2', '3']); // error: Illegal expression
end.


Objects are not classes, they don't know the Object Pascal style syntax 
for creating them, instead you need to use the syntax for objects from 
TP times:


=== code begin ===

program tobj;

type
  TMyObject = object
    constructor Create(text: array of String);
    destructor Destroy;
  end;
  PMyObject = ^TMyObject;

constructor TMyObject.Create(text: array of String);
begin
  Writeln(Length(text));
end;

destructor TMyObject.Destroy;
begin

end;

var
  o: PMyObject;
begin
  New(o, Create(['1', '2', '3']));
  Dispose(o, Destroy);
end.

=== code end ===

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Question on TFPGMap

[Sven Barth via fpc-pascal]

ppadilcdx--- via fpc-pascal  schrieb am
Mo., 2. Jan. 2023, 02:29:

> Sorry copy and paste error. d = decode. Corrected below.  But I think I
> see what you mean.  Just assigning a type to decode doesn't initialize
> it. But the compiler is happy with it, i.e. it doesn't call as illegal
> the statement "decode.create".
>

That is because constructors can also be called as regular methods. But the
instance will only be created if you call a constructor using the type.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Unrelated type helpers with the same members? Implement an interface with a type helper?

[Sven Barth via fpc-pascal]

Michael Van Canneyt via fpc-pascal 
schrieb am Fr., 23. Dez. 2022, 10:48:

>
>
> On Fri, 23 Dec 2022, Sven Barth via fpc-pascal wrote:
>
> > Michael Van Canneyt via fpc-pascal 
> > schrieb am Fr., 23. Dez. 2022, 08:18:
> >
> >>
> >>
> >> On Thu, 22 Dec 2022, Andrew Haines via fpc-pascal wrote:
> >>
> >>> Hi what I want to do is similar to this question here:
> >>>
> >>
> https://en.delphipraxis.net/topic/423-rtti-determine-record-helper-type-for-a-base-type/
> >>>
> >>> I am going to create multiple type helpers for enums and I would like
> to
> >> look
> >>> up the helper and use common methods AsString AsOrdinal to get/set the
> >>> values. I am recieving them as json that I dont have control over. I am
> >> using
> >>> typeinfo to fill in all the properties but I would like to convert the
> >>> strings I am receiving to the enum values semi-automatically.
> >>>
> >>> LString := 'STATUS';
> >>>
> >>> LHelper := GetHelper(LPropInfo^.PropType); // enum proptype
> >>
> >> Since there can be multiple type helpers for a type, this will never be
> >> possible. At best you would get a list.
> >>
> >> But I don't think there is even a list of type helpers per type.
> >> Sven will need to confirm.
> >>
> >
> > As the active helper(s) for a type change(s) depending on the current
> scope
> > (e.g. in unit A it might be a different helper than in unit B) this is
> not
> > possible. Also helpers are not in any way usable on their own except to
> > retrieve their RTTI information.
>
> But theoretically it should be possible to generate and get a list of all
> defined type helpers, whether they are in scope or not ?
>

No, because the compiler doesn't keep track of that. It's only interested
in what is in scope *right now*.


> If their RTTI could include a function that returns an interface, you could
> retrieve that and do as the OP suggests..
>

Don't make helpers to something that they're simply not there for.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Unrelated type helpers with the same members? Implement an interface with a type helper?

[Sven Barth via fpc-pascal]

Michael Van Canneyt via fpc-pascal 
schrieb am Fr., 23. Dez. 2022, 08:18:

>
>
> On Thu, 22 Dec 2022, Andrew Haines via fpc-pascal wrote:
>
> > Hi what I want to do is similar to this question here:
> >
> https://en.delphipraxis.net/topic/423-rtti-determine-record-helper-type-for-a-base-type/
> >
> > I am going to create multiple type helpers for enums and I would like to
> look
> > up the helper and use common methods AsString AsOrdinal to get/set the
> > values. I am recieving them as json that I dont have control over. I am
> using
> > typeinfo to fill in all the properties but I would like to convert the
> > strings I am receiving to the enum values semi-automatically.
> >
> > LString := 'STATUS';
> >
> > LHelper := GetHelper(LPropInfo^.PropType); // enum proptype
>
> Since there can be multiple type helpers for a type, this will never be
> possible. At best you would get a list.
>
> But I don't think there is even a list of type helpers per type.
> Sven will need to confirm.
>

As the active helper(s) for a type change(s) depending on the current scope
(e.g. in unit A it might be a different helper than in unit B) this is not
possible. Also helpers are not in any way usable on their own except to
retrieve their RTTI information.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to inline CompareFunc to Sort method in generic abstract class

[Sven Barth via fpc-pascal]

Am 20.11.2022 um 02:02 schrieb Hairy Pixels:



On Nov 20, 2022, at 4:26 AM, Sven Barth via fpc-pascal 
 wrote:

// this kind of constraint that uses T does not work yet
   generic TList> = class
 procedure Sort;
   end;

Does this mean the generic param “Comparer” has a constraint which is "specialize 
TComparer”? I’ve not ever considered this before but I think it solvers the 
problem where I suggested you could use something like traits.


Yes, those are type constraints. As long as you don't use types that 
were introduced in the same parameter list then it already works. E.g.:


=== code begin ===

program Project1;
{$mode objfpc}{$H+}

type
  generic TGen = class
  end;

  generic TTest> = class
  end;

  TGenLongInt = specialize TGen;
  TTestLongInt = specialize TTest;

begin

end.

=== code end ===

Though I wouldn't really compare that with traits.


  What is the challenge involved in implemented that so that it hasn’t been 
done yet? Just curious. :)


Mainly that a temporary symtable needs to be inserted before starting to 
parse the generic parameter types that is then passed along in the 
parser until the parameters are added to the final symbol table of the 
type or routine where the generic parameters reside.



And related since it comes to mind now, what is the reason generics inside of 
generics (like a generic method inside a generic class) are not supported and 
what challenges are involved?


The main problem is that the recording of the tokens and the use of the 
recorded tokens are managed correctly. E.g. should a generic method 
inside a generic class have it's tokens recorded when they're already 
recorded as part of the type and will be recorded again as a separate 
method when the class is specialized?


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to inline CompareFunc to Sort method in generic abstract class

[Sven Barth via fpc-pascal]

Am 14.11.2022 um 19:26 schrieb Vojtěch Čihák via fpc-pascal:

Hi,
  
I wrote a generic abstract class - a list based on dynamic array (i.e. array of T;) and this class can be specialized elsewhere with any type (records or classes).

Part of the class is sorting. There are more ways how to deliver *compare 
function* to sorting method. I can pass it as a parameter or I can define it 
as: function Compare(A, B: T): Integer; virtual; abstract;. But this way the 
function cannot be inlined.
  
Question: Is there a way how to *inline* compare function to sorting method in this general purpose generic abstract class?


Currently there is not. But once FPC supports reusing types in other 
specializations inside the generic parameter list you /should/ be able 
to do the following:


=== code begin ===

program tinline;

{$mode objfpc}

type
  generic TComparer = class
    class function Compare(aLeft, aRight: T): Integer;
  end;

  // this kind of constraint that uses T does not work yet
  generic TList> = class
    procedure Sort;
  end;

  TLongIntComparer = class(specialize TComparer)
    class function Compare(aLeft, aRight: T): Integer; inline;
  end;

class function TComparer.Compare(aLeft, aRight: T): Integer;
begin
  Result := 0;
end;

procedure TList.Sort;
begin
  { sort algorithm that calls Comparer.Sort which /should/ be inlined }
end;

class function TLongInt.Compare(aLeft, aRight: T): Integer;
begin
  if aLeft < aRight then
    Result := -1
  else if aLeft > aRight then
    Result := 1
  else
    Result := 0;
end;

var
  l: specialize TList;
begin
  l : =specialize TList.Create;
  l.Sort;
end.

=== code end ===

I can't test this currently whether it would really work due to the 
missing functionality, but it's at least possible.


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to inline CompareFunc to Sort method in generic abstract class

[Sven Barth via fpc-pascal]

Am 18.11.2022 um 20:44 schrieb Flávio Etrusco via fpc-pascal:



Em seg., 14 de nov. de 2022 15:26, Vojtěch Čihák via fpc-pascal 
 escreveu:


Hi,

I wrote a generic abstract class - a list based on dynamic array
(i.e. array of T;) and this class can be specialized elsewhere
with any type (records or classes).
Part of the class is sorting. There are more ways how to deliver
*compare function* to sorting method. I can pass it as a parameter
or I can define it as: function Compare(A, B: T): Integer;
virtual; abstract;. But this way the function cannot be inlined.

Question: Is there a way how to *inline* compare function to
sorting method in this general purpose generic abstract class?

Thanks.

PS: The gain is 6-7%.


Hi,

What do you mean by "be inlined"? The 'inline' directive instructs the 
compiler (or is it the linker? ) to try copying the whole function 
inline, also avoiding the call (stack) setup; you can't do this for 
this for a general purpose method.


Inlining is done by the compiler, not the linker. Also inlining does 
work for methods (at least in general; there are exceptions to this, 
e.g. if the method is virtual or uses "inherited"). What it can't be 
done with is method pointers (or function pointers).


Regards,
Sven___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Program efficiency

[Sven Barth via fpc-pascal]

James Richters via fpc-pascal  schrieb am
Mi., 9. Nov. 2022, 13:47:

> In other words.. is
>
> A:=(B+C/D)-E^F;
> G:=H*(I+J);
> K:=L+M/N;
> O:= A+G-K;
>
> Less efficient than
> O:= ((B+C/D)-E^F)+ (H*(I+J))-(L+M/N);
>
> Or does it end up being the same when it's done?
>

The compiler will insert temporary variables anyway when necessary (so even
your first example might infact contain more variables and your second will
very likely contain temporaries).
Using optimizations (especially regvars, used by default in -O2) might
improve this independent of whether you use variables yourself or not.

But in general: you should look at other things to optimize and only come
back to this when you have nothing easier to improve.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal