What would really be nice is a way for the compiler to do this
MyFunction(obj; SizeOfOjb:Integer = Sizeof(Obj):someOptionalReturnType;
Since the compiler knows at compile time the size of each type coming in the pipe it should be able to insert the size of the object on the fly
For example
MyFunction(AnIntegerOfSomeSort);
The compiler would then generate code like this
MyFunction(AnIntegerOfSomeSort, SizeOf(Obj)=4);
basically a way to know how large of an object the first parameter is looking at..
Also it would be nice if some how the compiler could build an "array of reference" instead of CONST so one could write back to the source elements or make faster code for the compiler to simply supply refence instead of copying over all the elements thus forming an array of pointers..
Procedure MyElements(Array of Refence);
MyElements([SomeInteger, SomeWord, SomeVariant, SomeString]);
basically the array would be the TYPE and only the Pointer to the item.. so the TYPE would be the source of the element not a pointer but the element of the Variant record would define the pointer to the source element..
Or did I miss something ?
They almost do work actually but there appears to be a bug in the compiler///
I wanted to let everyone know that this code fails with 3.2.0 compiler.. It forgets to insert the object reference when inlining ..
so this is an inline bug and without inline working this fix for classes isn't going to work..
I am sorry to disappoint you but yes, its a bug and I say that because it seems we try to be Delphi compliant ..
...
Like I said, this works perfectly fine with Delphi and 3.0.4 down..
I can't be the only one that has done code this way..
I am sorry to disappoint you but yes, its a bug and I say that because it seems we try to be Delphi compliant ..
Here is a more simplified chuck of code that breaks with 3.2.0 and maybe upwards..
This all works fine with 3.0.4 and a few down that I have used.
and to top it off, it also works in DELPHI and has for years..
Or the code is not correct, and then FPC should not compile it at all, and abort the compilation with an error message.
PS C:\fpc\git> fpc -FEtestoutput .\fpctests\tinline.pp
Free Pascal Compiler version 3.2.0 [2020/07/07] for x86_64
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Win64 for x64
Compiling .\fpctests\tinline.pp
tinline.pp(24,11) Warning: Function result variable does not seem to be initialized
Linking testoutput\tinline.exe
49 lines compiled, 0.3 sec, 72208 bytes code, 5236 bytes data
1 warning(s) issued
Yes a reference to the return is the problem and was solved using inline which stull works in Delphi of course and no longer in fpc.
Its like getting the newer model car only now there is no engine in it cuase its deemed unneeded
I stopped the converting of the c++ program and moving to Delphi now.
Fpc needs to fix this or give a reference return option.
Fpc needs to fix this or give a reference return option.
Function name(....):var type;
Would be a good start.
I don't want to harp on this but given it an option for VAR return is a simple matter.
So I am stuck at 3.0.4 and now moving my stuff over to Delphi for future work..
There is a near infinite amount of code that is incorrect, but that the compiler compiles.
And hey, look, the compiler does warn you:Code: [Select]PS C:\fpc\git> fpc -FEtestoutput .\fpctests\tinline.pp
Free Pascal Compiler version 3.2.0 [2020/07/07] for x86_64
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Win64 for x64
Compiling .\fpctests\tinline.pp
tinline.pp(24,11) Warning: Function result variable does not seem to be initialized
Linking testoutput\tinline.exe
49 lines compiled, 0.3 sec, 72208 bytes code, 5236 bytes data
1 warning(s) issued
I don't think any compiler has been developed yet that can correctly guess what the programmer meant when writing the program.And hey, look, the compiler does warn you:Code: [Select]PS C:\fpc\git> fpc -FEtestoutput .\fpctests\tinline.pp
Free Pascal Compiler version 3.2.0 [2020/07/07] for x86_64
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Win64 for x64
Compiling .\fpctests\tinline.pp
tinline.pp(24,11) Warning: Function result variable does not seem to be initialized
Linking testoutput\tinline.exe
49 lines compiled, 0.3 sec, 72208 bytes code, 5236 bytes data
1 warning(s) issued
But it is a warning, not an error. If there actually was something incorrect, it should give an error
Also with Lazarus warnings are hard to find
And why do I need a compiler patch ? You only need to undo what is now broken.
And I am only talking about compiled code that is incorrect with one version of FPC, but outputs the correct output with other versions of FPC
And hey, look, the compiler does warn you:Code: [Select]PS C:\fpc\git> fpc -FEtestoutput .\fpctests\tinline.pp
Free Pascal Compiler version 3.2.0 [2020/07/07] for x86_64
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Win64 for x64
Compiling .\fpctests\tinline.pp
tinline.pp(24,11) Warning: Function result variable does not seem to be initialized
Linking testoutput\tinline.exe
49 lines compiled, 0.3 sec, 72208 bytes code, 5236 bytes data
1 warning(s) issued
But it is a warning, not an error. If there actually was something incorrect, it should give an error
now you can do this with Objects because they are static basically and Records but it seems the team has a rejection to doing this for Class pointers or even providing an option for a reference, so you use what works like I do..
This all broke for Class pointers or any simply type starting with 3.2.0 where an INLINE proxy can be used to simulate the same effect. But as it appears things are going the way of Dodo birds
Simply put Fpc needs a optional Return by reference via a function not a OUT or VAR in the input parameters.Unfortunately I have little experience in C++ and still trying to understand the problem... Could you please provide some C++ or C code that could illustrate a "result by reference" relationship to the "inline function" problem (or abuse, I suppose)?
Function Name (….) VAR TheTYPE;
C++ has been doing this for years, C does it via a pointer but C++ has the reference "&" which forces the compiler to have a valid pointer to the return object during the cycle life of the function.
Fpc and Delphi already does this if the return type is a large data type, a pointer in the background is created and given as a working resource during the life of the function body... So the added feature is a nothing operation to handle because it is already being done..
This all broke for Class pointers or any simply type starting with 3.2.0 where an INLINE proxy can be used to simulate the same effect. But as it appears things are going the way of Dodo birds
...It seems that var parameters work in operator overloading.
but then why shouldn't there be such a thing
operator := (var R: String; var L: TForm1) operator + (var R1, R2: Integer):TForm1
Just RTFM and documentation say that operator overloading definition is like a function definition....It seems that var parameters work in operator overloading.
but then why shouldn't there be such a thing
operator := (var R: String; var L: TForm1) operator + (var R1, R2: Integer):TForm1
The following code compiles:
...
Is this intentional behavior? I tested trunk version from a few months ago.
Is this intentional behavior? I tested trunk version from a few months ago.
That works because the compiler creates a reference back to the return of the record.. As I stated before, records are large data types and the compiler creates a reference back to it..
But it is a warning, not an error. If there actually was something incorrect, it should give an error
No, because the compiler does not know what the developer might have intended here
And if there is anything undefined in the language, it needs to be removed
And if there is anything undefined in the language, it needs to be removed
There are always going to be some things in any language that are undefined -- no specific outcome has been defined for that scenario. The only way to avoid that is to allow zero changes to the operating environment that the compiler will live in, and produce a mass of documentation to cover every single specification.
But if the programmer writes some code doing things that are not covered in the documentation, the compiler should say they are not covered and refuse to compile it. Not like now, where it finds something that is not covered, and then does random nonsense
For trivial languages one could build such compilers in a few minutes.
But if the programmer writes some code doing things that are not covered in the documentation, the compiler should say they are not covered and refuse to compile it.
I'm not sure why you believe this to be a reasonable expectation. Can you point to any language compiler in use today which comes close to behaving like this?
I'm not sure why you believe this to be a reasonable expectation. Can you point to any language compiler in use today which comes close to behaving like this?
It is one of the biggest reasons people are making new languages nowadays
Spark (Ada), Wuffs, Idris, Agda, ATS are some
They have an integrated theorem prover to prove everything in the code is correct