Lazarus

Programming => General => Topic started by: jamie on February 20, 2021, 04:25:29 pm

Title: converting C++ over laz, issues with template operators conversion
Post by: jamie on February 20, 2021, 04:25:29 pm
Does any one have a suggestion as to how to get this working In laz/fpc?
I know we can't use << or >> as operator overloads so I was going to use something different..

even a simple := will do but I can't seem to come up with an operator overload that works with a  <T> define.
Code: Pascal  [Select][+][-]
  1.         ////////////////////////////////////////////////////
  2.         // The default operators
  3.         //
  4.         template<class T> CStream &operator<<(const T& a)
  5.         {
  6.                 Write(&a, sizeof(T));
  7.                 return *this;
  8.         }
  9.  
  10.         template<class T> CStream &operator>>(T& a)
  11.         {
  12.                 Read(&a, sizeof(T));
  13.                 return *this;
  14.         }
  15.  

Cstream is the class, I need to have a operator defined that accepts a generic for type etc..
how would I go about this ? It has to remain as a class not a record.

Title: Re: converting C++ over laz, issues with template operators conversion
Post by: PascalDragon on February 21, 2021, 05:13:20 pm
It might be better to use a fluent interfaces approach instead as FPC neither supports generic operator overloads nor implicit conversions that would be required nor operators inside classes. Instead you might want to do a "fluent interface" approach:

Code: Pascal  [Select][+][-]
  1. program topovld;
  2.  
  3. {$mode objfpc}{$H+}
  4. {$modeswitch advancedrecords}
  5.  
  6. type
  7.   TMyTest = class
  8.     generic function Add<T>(aArg: T): TMyTest;
  9.   end;
  10.  
  11. { TMyTest }
  12.  
  13. generic function TMyTest<T>.Add(aArg: T): TMyTest;
  14. begin
  15.   { whatever }
  16.   Result := Self;
  17. end;
  18.  
  19. var
  20.   t: TMyTest;
  21. begin
  22.   t.specialize Add<LongInt>(42).specialize Add<String>('Hello');
  23. end.

Ryan Joseph is currently working on a feature (called implicit function specializations) that would shorten the calls to this:

Code: Pascal  [Select][+][-]
  1. t.Add(42).Add('Hello');
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: PascalDragon on February 22, 2021, 09:26:12 am
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..

I don't understand what you're trying to achieve here.

However what stops you from doing something like this:

Code: Pascal  [Select][+][-]
  1. procedure FoobarInternal(const aArg; aSize: SizeInt);
  2. begin
  3.   // whatever
  4. end;
  5.  
  6. generic procedure Foobar<T>(const aArg: T);
  7. begin
  8.   FoobarInternal(aArg, SizeOf(aArg));
  9. end;

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 ?

Best use an array of pointers and an additional parameter that describes what these pointers point to (similar to what SScanf (https://www.freepascal.org/docs-html/rtl/sysutils/sscanf.html) does).

They almost do work actually but there appears to be a bug in the compiler///

No, there is not. Classes are implicit pointers types. Thus you're essentially operating either on garbage or on a Nil value (likely the former if it doesn't crash right away). You need to explicitly instantiate the result:

Code: Pascal  [Select][+][-]
  1. operator := (R: String): TForm1;
  2. begin
  3.   Result := TForm1.Create(Nil);
  4.   Result.Caption := R;
  5. end;

Operators can not modify the left side. It might feel like this for records and objects due to how they are passed on the ABI level, but all this is implementation specific. Generally assume that the Result is in an invalid state.
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: PascalDragon on February 25, 2021, 08:54:22 am
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..

No, this is not a bug. You're abusing implementation details and we give no guarantee for them to stay the same across versions. Even optimizations in 3.0.4 might result in your code no longer working.
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: ASBzone on February 26, 2021, 02:49:13 am
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 don't think it is fair to call something a bug when the behavior is not specifically defined, or an actual feature, but the exploitation of a particular compiler implementation.

Sure, it works on certain platforms, but that is not "by design" but simply a by product of not doing it differently.
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: PascalDragon on February 26, 2021, 09:24:59 am
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..

So? It's still using undefined behaviour. That can be very nicely seen if the inline is disabled:

Code: Pascal  [Select][+][-]
  1. program tinline;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. uses
  6.   SysUtils;
  7.  
  8. type
  9.   TForm1 = class
  10.   private
  11.     fCaption: String;
  12.     function GetCaption: String;
  13.     procedure SetCaption(const aValue: String);
  14.   published
  15.     property Caption: String read GetCaption write SetCaption;
  16.   end;
  17.  
  18. Procedure Ox(A:TForm1;Value:Integer);
  19. Begin
  20.  A.Caption := value.Tostring;
  21. End;
  22. operator := (R:Integer):Tform1;{inline;}
  23. Begin
  24.  Ox(Result,R);
  25. end;
  26.  
  27. var
  28.   Form1: TForm1;
  29.  
  30. { TForm1 }
  31.  
  32. function TForm1.GetCaption: String;
  33. begin
  34.   Result := fCaption;
  35. end;
  36.  
  37. procedure TForm1.SetCaption(const aValue: String);
  38. begin
  39.   fCaption := aValue;
  40. end;
  41.  
  42. begin
  43.   Form1 := TForm1.Create;
  44.   try
  45.     Form1 := 1;
  46.   finally
  47.     Form1.Free;
  48.   end;
  49. end.

The generated assembly code on i386-win32 looks like this for the assignment operator:

Code: ASM  [Select][+][-]
  1. .section .text.n_p$tinline_$$_assign$longint$$tform1,"x"
  2.         .balign 16,0x90
  3. .globl  P$TINLINE_$$_assign$LONGINT$$TFORM1
  4. P$TINLINE_$$_assign$LONGINT$$TFORM1:
  5. # [23] Begin
  6.         pushl   %ebp
  7.         movl    %esp,%ebp
  8.         leal    -8(%esp),%esp
  9. # Var R located at ebp-4, size=OS_S32
  10. # Var $result located at ebp-8, size=OS_32
  11.         movl    %eax,-4(%ebp)
  12. # [24] Ox(Result,R);
  13.         movl    -4(%ebp),%edx
  14.         movl    -8(%ebp),%eax
  15.         call    P$TINLINE_$$_OX$TFORM1$LONGINT
  16. # [25] end;
  17.         movl    -8(%ebp),%eax
  18.         movl    %ebp,%esp
  19.         popl    %ebp
  20.         ret

Here -8(%ebp) contains the Result value and as you can see it is not initialized in any way, thus Ox will access garbage. Now inlining has the restriction of not changing the behaviour of the code. Thus FPC 3.2.0 behaves correctly here. FPC 3.0.4 generates nearly identical code here if inlining is disabled.

That it behaves differently with active inlining on 3.0.4 or even Delphi is no reason that the behaviour of these is correct only that their code generators happen to generate the code in a way this works. This could behave totally different on a different platform, with different optimizations or e.g. on a LLVM-based backend which is known for aggressive optimizations (especially when undefined behaviour like this is involved).

Also depending on the code I can also get the same “incorrect” (from your PoV) behavior in FPC 3.0.4 which further shows that you're totally relying on circumstances that might change without any warning.

So, yeah, just don't do stuff like that.
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: BeniBela on February 27, 2021, 01:53:06 pm
This is absolutely a compiler bug

Either the code is correct, and then FPC should compile it to a working program

Or the code is not correct, and then FPC should not compile it at all, and abort the compilation with an error message.


In any case, what FPC does is wrong


Look what happens if you do it in Java:

Code: Java  [Select][+][-]
  1.  
  2. public class xy{
  3.  StringBuilder test(){
  4.    StringBuilder result;
  5.    result.append("foo");
  6.    return result;
  7.  }
  8. }

Code: Bash  [Select][+][-]
  1. $  javac xy.java
  2. xy.java:5: error: variable result might not have been initialized
  3.    result.append("foo");
  4.    ^
  5. 1 error
  6.  
  7.  
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: PascalDragon on February 27, 2021, 03:12:03 pm
Or the code is not correct, and then FPC should not compile it at all, and abort the compilation with an error message.

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

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.

There is nothing to fix.
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: FPK on February 27, 2021, 04:44:58 pm

Fpc needs to fix this or give a reference return option.

Function name(....):var type;

Would be a good start.

... and then we get complains that

Function name(....):var type;
var
  v : type;
begin
   ...
   dosomething(v);
   ...
   result:=v;
end;

works in version 3.2.2134523462 but not in version 3.2.2134523463.

Extra work and still complaints. So not really an option.
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: FPK on February 27, 2021, 05:27:29 pm
I don't want to harp on this but given it an option for  VAR return is a simple matter.

So you have a compiler patch ready?

Quote
So I am stuck at 3.0.4 and now moving my stuff over to Delphi for future work..

Delphi is always a good choice.
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: BeniBela on February 27, 2021, 07:38:08 pm

There is a near infinite amount of code that is incorrect, but that the compiler compiles.

Then FPC has infinitely many bugs.

At least they are countable

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

With reliable languages like Ada/SPARK or Wuffs such things do not happen


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
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: korba812 on February 28, 2021, 12:42:18 am
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
I don't think any compiler has been developed yet that can correctly guess what the programmer meant when writing the program.
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: PascalDragon on March 01, 2021, 01:17:58 pm
And why do I need a compiler patch ? You only need to undo what is now broken.

Again, there is nothing broken in the compiler. Your code is broken. That it hasn't failed on Delphi does not mean that it isn't.

And FPK meant a patch regarding your reference result suggestion.

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

Code compiling in version A does not mean that it is correct code in version A. In this specific case it's abusing implementation details both in 3.0.4 and in Delphi (the former printing the below mentioned warning as well). I've even managed to get the example I posted to work "incorrectly" with 3.0.4 as well just by changing some settings.

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

No, because the compiler does not know what the developer might have intended here. It simply points out that there might be something fishy there and if you ignore that and go your merry way then that's your problem.

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

Because that's how the ABI defines it (in this case "values of pointer size"). Adhering to the ABI is important for compatibility to other compilers, most importantly the platform's C compiler. This way one can for example return a class instance from the Pascal side as an opaque pointer type on the C side.
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: jamie on March 01, 2021, 04:19:26 pm
Please no more. I can't take nonsense.
I tried to remove complete thread with no luck.

I moved it to Delphi, it all works there.
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: korba812 on March 05, 2021, 12:43:52 am
First of all, maybe I don't fully understand the problem and have no idea how the compiler works, but ...
I imagine operator overloading as a function with the appropriate parameters and return value.
So
Code: Pascal  [Select][+][-]
  1. operator := (R: String): TForm1
will be translated to
Code: Pascal  [Select][+][-]
  1. function assignemt(R: String): TForm1
If possible, the inaccuracy introduced in Delphi could be formalized, but by introducing a different format for this situation - as a procedure with the additional var parameter.
Eg:
Code: Pascal  [Select][+][-]
  1. operator := (R: String; var L: TForm1)
will be translated to
Code: Pascal  [Select][+][-]
  1. procedure assignemt(R: String; var L: TForm1)
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

Title: Re: converting C++ over laz, issues with template operators conversion
Post by: jamie 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
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: PascalDragon 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.
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: korba812 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)?
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: korba812 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.
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: jamie 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.

                               
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: korba812 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++?
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: korba812 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. :(
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: PascalDragon 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.
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: BeniBela 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
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: PascalDragon 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.
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: ASBzone 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.
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: BeniBela 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.

Title: Re: converting C++ over laz, issues with template operators conversion
Post by: PascalDragon 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.
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: ASBzone 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.)
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: BeniBela 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
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: ASBzone on March 14, 2021, 01:11:58 am
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

Interesting.   That (the dispute in this thread) doesn't seem to be what integrated theorem provers are intending to address, according to the following link, but the entire thing is new to me, so...

https://en.wikipedia.org/wiki/ATS_(programming_language)
Title: Re: converting C++ over laz, issues with template operators conversion
Post by: jamie on March 14, 2021, 03:15:41 pm
all of this mess just because I needed a Reference return?

One that is documented so that it does not become a victim of a Oops and then blanket statement out.

Other languages support this.


Have a good day
TinyPortal © 2005-2018