Recent

Author Topic: converting C++ over laz, issues with template operators conversion  (Read 8646 times)

jamie

  • Hero Member
  • *****
  • Posts: 4327
Re: converting C++ over laz, issues with template operators conversion
« Reply #15 on: March 05, 2021, 11:55:06 pm »
No of which would solve the issue using 3.2.0

Simply put Fpc needs a optional Return by reference via a function not a OUT or VAR in the input parameters.


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
The only true wisdom is knowing you know nothing

PascalDragon

  • Hero Member
  • *****
  • Posts: 2863
  • Compiler Developer
Re: converting C++ over laz, issues with template operators conversion
« Reply #16 on: March 06, 2021, 03:49:20 pm »
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

Again, you're using undefined behavior. That your code fails if you leave out the inline shows that your code is wrong, because inlining is not supposed to change the behavior!

And your code will fail in Delphi as well, especially if you enable optimizations (tested with Delphi 10.2):

Code: Pascal  [Select][+][-]
  1. program tinline;
  2.  
  3. {$APPTYPE CONSOLE}
  4. { the code will fail without this directive as well }
  5. {$OPTIMIZATION ON}
  6.  
  7. type
  8.   TTest = class
  9.   public
  10.     Test: String;
  11.   end;
  12.  
  13. function Test: TTest; inline;
  14. begin
  15.   Result.Test := 'Foobar';
  16. end;
  17.  
  18. procedure Foobar;
  19. var
  20.   t: TTest;
  21. begin
  22.   t := TTest.Create;
  23.   try
  24.     t := Test;
  25.   finally
  26.     t.Free;
  27.   end;
  28. end;
  29.  
  30. begin
  31.   Foobar;
  32. end.

korba812

  • Full Member
  • ***
  • Posts: 159
Re: converting C++ over laz, issues with template operators conversion
« Reply #17 on: March 06, 2021, 09:20:45 pm »
Simply put Fpc needs a optional Return by reference via a function not a OUT or VAR in the input parameters.

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
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)?

korba812

  • Full Member
  • ***
  • Posts: 159
Re: converting C++ over laz, issues with template operators conversion
« Reply #18 on: March 06, 2021, 10:48:30 pm »
...
but then why shouldn't there be such a thing
Code: Pascal  [Select][+][-]
  1. operator := (var R: String; var L: TForm1)
  2. operator + (var R1, R2: Integer):TForm1
It seems that var parameters work in operator overloading.
The following code compiles:
Code: Pascal  [Select][+][-]
  1. program Project1;
  2.  
  3. type
  4.   TMyRec = record
  5.     Foo: Integer;
  6.   end;
  7.  
  8. operator := (var L: Integer): TMyRec;
  9. begin
  10.   Result.Foo := L;
  11.   Inc(L);
  12. end;
  13.  
  14. operator + (var L1: TMyRec; var L2: Integer): TMyRec;
  15. begin
  16.   Result.Foo := L1.Foo + L2;
  17.   Inc(L1.Foo);
  18.   Inc(L2);
  19. end;
  20.  
  21. var
  22.   R1, R2: TMyRec;
  23.   I: Integer;
  24. begin
  25.   I := 10;
  26.   R1 := I;
  27.   R2 := I;
  28.   WriteLn(R1.Foo);
  29.   WriteLn(R2.Foo);
  30.   WriteLn(I);
  31.   R2 := R1 + I;
  32.   WriteLn(R1.Foo);
  33.   WriteLn(R2.Foo);
  34.   WriteLn(I);
  35. end.
results:
Code: Pascal  [Select][+][-]
  1. 10
  2. 11
  3. 12
  4. 11
  5. 22
  6. 13
Is this intentional behavior? I tested trunk version from a few months ago.

jamie

  • Hero Member
  • *****
  • Posts: 4327
Re: converting C++ over laz, issues with template operators conversion
« Reply #19 on: March 06, 2021, 11:06:49 pm »
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..

 Class pointers are not large data types and it just simply recreates one locally or has a junk pointer if you don't create one locally in the operator function and there for makes it impossible to code out a function not a procedure in your code that can interact with the return object without actually creating one in the function...

 C++ does this sort of thing a lot with the & symbol... It tells the compiler to use a pointer that is initialized to the returning object so that one can directly interact on the return object inside the function as if it was already created..

  of course you can create a new class inside the function if you wish, it will only be interacting with the returned object which lives outside the function body but you have access to it via the REFERENCE pointer.


 So looking at a procedure or Function (Var Name:AClassType), here the NAME is a reference back to the input object but that isn't what I want, I want to code it like a function and this gain access to the returning object's real body not have the function create a new object(Class)…

So using the RETURN.SomeMember := ?  will simply directly interact with the object that would normally get overwritten when the function returns..
 
 Why would want to do such things you may ask?

    it is to make a choice if you want to reuse an existing object that is already living and simply modify it a little there by making a change to it or totally replace it which then starts a memory operation .

  And all of this us being done in a FUNCTION way not a procedure way so it looks natural...


 The simple fix for this would be to give a new option when defining a function as I said before...

 Function NAme(…..) VAR ReturnType;
                               ^^^

that would force the compiler to call it the same way as it would if it were dealing with a Large Data type, a record for example.

Also, there should be some restrictions on its use, with the {$E+}  on, the compiler should not allow these types of functions to be used as procedures.

                               
« Last Edit: March 06, 2021, 11:10:02 pm by jamie »
The only true wisdom is knowing you know nothing

korba812

  • Full Member
  • ***
  • Posts: 159
Re: converting C++ over laz, issues with template operators conversion
« Reply #20 on: March 06, 2021, 11:20:53 pm »
I generally know what "result by reference" is in C ++, but I don't know what that has to do with the following code:
Code: Pascal  [Select][+][-]
  1. function Test: TTest; inline;
  2. begin
  3.   Result.Test := 'Foobar';
  4. end;
  5.  
Could you please show me a working equivalent in C++?

korba812

  • Full Member
  • ***
  • Posts: 159
Re: converting C++ over laz, issues with template operators conversion
« Reply #21 on: March 07, 2021, 12:19:54 am »
...
but then why shouldn't there be such a thing
Code: Pascal  [Select][+][-]
  1. operator := (var R: String; var L: TForm1)
  2. operator + (var R1, R2: Integer):TForm1
It seems that var parameters work in operator overloading.
The following code compiles:
...
Is this intentional behavior? I tested trunk version from a few months ago.
Just RTFM and documentation say that operator overloading definition is like a function definition.

edit

However, it could be explicitly mentioned in documentation as it is not clear at present.

edit

it is possible to declare a default value of a parameter
Code: Pascal  [Select][+][-]
  1. operator - (L1: TMyRec; L2: Integer = 3): TMyRec;
But it cannot be used. :(
« Last Edit: March 07, 2021, 01:16:49 am by korba812 »

PascalDragon

  • Hero Member
  • *****
  • Posts: 2863
  • Compiler Developer
Re: converting C++ over laz, issues with template operators conversion
« Reply #22 on: March 07, 2021, 02:54:05 pm »
Is this intentional behavior? I tested trunk version from a few months ago.

It's at least not explicitely considered as supported.

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..

The compiler does not do anything specific to support this, it's merely an artefact of the code generation. Delphi itself warns that the Result is not initialized and depending on the optimization settings it will fail in Delphi as well.

BeniBela

  • Hero Member
  • *****
  • Posts: 784
    • homepage
Re: converting C++ over laz, issues with template operators conversion
« Reply #23 on: March 08, 2021, 01:53:33 pm »


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

It does not matter what the developer has intended

With a stable language and a stable compiler, you just compile and run the program, and whatever the program does, is what the program is supposed to do

And if there is anything undefined in the language, it needs to be removed

PascalDragon

  • Hero Member
  • *****
  • Posts: 2863
  • Compiler Developer
Re: converting C++ over laz, issues with template operators conversion
« Reply #24 on: March 09, 2021, 09:15:57 am »
And if there is anything undefined in the language, it needs to be removed

Welcome to reality.

ASBzone

  • Hero Member
  • *****
  • Posts: 587
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: converting C++ over laz, issues with template operators conversion
« Reply #25 on: March 10, 2021, 03:49:09 am »
And if there is anything undefined in the language, it needs to be removed

Huh?

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.

That's not how things are done.
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.0.13 r64843 / FPC v3.2.1-r49055 (via FpcUpDeluxe) -- Windows 64-bit install w/Win32 and Linux/Arm cross-compiles
Primary System: Windows 10 Pro x64, Version 2009 (Build 19042)
Other Systems: Windows 10 Pro x64, Version 2009 (Build 19042) or greater

BeniBela

  • Hero Member
  • *****
  • Posts: 784
    • homepage
Re: converting C++ over laz, issues with template operators conversion
« Reply #26 on: March 10, 2021, 06:49:15 pm »
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.

The documentation does not need to cover everything.


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.


PascalDragon

  • Hero Member
  • *****
  • Posts: 2863
  • Compiler Developer
Re: converting C++ over laz, issues with template operators conversion
« Reply #27 on: March 11, 2021, 09:07:30 am »
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

That is not how things work, especially not...

For trivial languages one could build such compilers in a few minutes.

... with a non-trivial language like Pascal that additionally has a ton of historic package.

ASBzone

  • Hero Member
  • *****
  • Posts: 587
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: converting C++ over laz, issues with template operators conversion
« Reply #28 on: March 11, 2021, 04:59:28 pm »
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?


(Mind you, just because no one is doing a thing does not necessarily mean that the thing is wrong, but it is a likely indication that it is not trivial.)
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.0.13 r64843 / FPC v3.2.1-r49055 (via FpcUpDeluxe) -- Windows 64-bit install w/Win32 and Linux/Arm cross-compiles
Primary System: Windows 10 Pro x64, Version 2009 (Build 19042)
Other Systems: Windows 10 Pro x64, Version 2009 (Build 19042) or greater

BeniBela

  • Hero Member
  • *****
  • Posts: 784
    • homepage
Re: converting C++ over laz, issues with template operators conversion
« Reply #29 on: March 13, 2021, 07:36:37 pm »
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

 

TinyPortal © 2005-2018