Recent

Author Topic: Question about assignment operator overloading example in the Reference guide  (Read 5722 times)

440bx

  • Hero Member
  • *****
  • Posts: 3944
Hello,

Starting on page 212 about overloading the assignment operator the Reference Guide gives an example starting with the definition of a complex data type as:

Code: Pascal  [Select][+][-]
  1. type
  2.   complex = record
  3.     re : real;
  4.     im : real;
  5.   end;
  6.  
then states "This system can be used to declare a new type, and define an assignment for that type. For instance, to be able to assign a newly defined type ’Complex’ "

Code: Pascal  [Select][+][-]
  1. Var
  2.   C, Z : Complex; // New type complex
  3.  
  4. begin
  5.   Z := C;         // assignments between complex types.
  6. end;
  7.  

followed by: "The following assignment operator would have to be defined:"
Code: Pascal  [Select][+][-]
  1. Operator := (C : Complex) z : complex;
  2.  
but that makes the compiler unhappy, outputting the error message:

"Error: impossible to overload assignment for equal types"

which makes sense since the overload in that case is unnecessary.

Is the example faulty or am I missing its point ?

I also checked the ucomplex unit to see if an assignment operator was defined for a (complex, complex) tuple and there wasn't one. That example is at least confusing.

Thank you for your help.


(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Blaazen

  • Hero Member
  • *****
  • Posts: 3237
  • POKE 54296,15
    • Eye-Candy Controls
I can confirm with trunk. What is your FPC version?

The guide should be for 3.0.4, page is here: https://www.freepascal.org/docs-html/ref/refse101.html#x210-23200015.3

Maybe it is outdated part of guide. AFAIK only this overload is necessary now:
Code: Pascal  [Select][+][-]
  1. operator := (r : real) z : complex;
  2.      begin
  3.        z.re:=r;
  4.        z.im:=0.0;
  5.     end;
Lazarus 2.3.0 (rev main-2_3-2863...) FPC 3.3.1 x86_64-linux-qt Chakra, Qt 4.8.7/5.13.2, Plasma 5.17.3
Lazarus 1.8.2 r57369 FPC 3.0.4 i386-win32-win32/win64 Wine 3.21

Try Eye-Candy Controls: https://sourceforge.net/projects/eccontrols/files/

440bx

  • Hero Member
  • *****
  • Posts: 3944
Hi Blaazen,

the Free Pascal Reference Guide I'm reading is stated to be for version 3.0.2.  Document version 3.0.2 as well, dated February 2017.

my environment is as follows:

Free Pascal v3.0.4
Lazarus v.1.8.2
Windows 7 64bit.


In the page you linked to, the compiler will complain about the statement:

Code: Pascal  [Select][+][-]
  1. Operator := (C : Complex) z : complex;

located on the 11th line (not counting blank lines.) It makes sense for the compiler to complain since for the same type, there is no need for an assignment overload which could actually cause problems.

It looks like the web page has the same problem as the Reference Guide pdf I am reading.

Thank you for looking into it.




(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

mm7

  • Full Member
  • ***
  • Posts: 193
  • PDP-11 RSX Pascal, Turbo Pascal, Delphi, Lazarus
Quote
It makes sense for the compiler to complain since for the same type, there is no need for an assignment overload which could actually cause problems.

not necessarily.
For example I want to track all assignments for a particular type and log call stack.
Or I want to check ranges or other conditions. Or ... whatever.

I think disabling assignment overload for same type is artificial. If needed it should be turned on with a pragma or a compiler key.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
For example I want to track all assignments for a particular type and log call stack.
Or I want to check ranges or other conditions. Or ... whatever.

Complex variables that have their own garbage collection or compression. Objects (represented by address) which might or might not create a new object on assignment. Large and complex structures which would normally have to be copied element-by-element.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
I think disabling assignment overload for same type is artificial. If needed it should be turned on with a pragma or a compiler key.

No, people will abuse such features and then complain that something does not work. So better not to open such possibilities. Object Pascal is not C++ after all...

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
Except the manual still uses a deprecated type: real. Something should be done about that. real is a bit too c'sh while it always meant something different and was once a first class citizen of the language but isn't anymore.
It only confuses. What does it mean? 48 bit Pascal type? 32 bit single? or 64 bit double? That should be gone from the manuals.
« Last Edit: February 27, 2020, 01:11:07 pm by Thaddy »
Specialize a type, not a var.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
real is a bit too c'sh

Don't please. I agree that "single" and "double" are better, but criticising "real" (or any other language or documentation feature) simply because it is "too C-ish" is a very weak argument.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
real is a bit too c'sh

Don't please. I agree that "single" and "double" are better, but criticising "real" (or any other language or documentation feature) simply because it is "too C-ish" is a very weak argument.

MarkMLl
Actually it is a very strong argument, because a Pascal real is a distinct Pascal 48 bit type and differs greatly from C. That was the point.
Specialize a type, not a var.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
real is a bit too c'sh
Don't please. I agree that "single" and "double" are better, but criticising "real" (or any other language or documentation feature) simply because it is "too C-ish" is a very weak argument.
Actually it is a very strong argument, because a Pascal real is a distinct Pascal 48 bit type and differs greatly from C. That was the point.

I'll agree that 48-bit floating point is pretty unlike anything else, let alone C. But at that point I can't see any reason to introduce C into the discussion: by all means say "Pascal reals don't comply with IEEE-754" but don't make it look as though everybody in the community is out to pick a "my language is better than yours" fight.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
I'll agree that 48-bit floating point is pretty unlike anything else, let alone C. But at that point I can't see any reason to introduce C into the discussion: by all means say "Pascal reals don't comply with IEEE-754" but don't make it look as though everybody in the community is out to pick a "my language is better than yours" fight.

Agreed. Real is anything, but C-ish, cause C does not have such a type.

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
Agreed. Real is anything, but C-ish, cause C does not have such a type.
C does not even have strings, but these C people call everything that smells like a floating point: real. (lest you forgot!)
Only Pascal has a real real type.... ;D >:( with a silly bit count... >:D
Specialize a type, not a var.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Perhaps we should rename "real" to be "trump": everybody agrees it exists but nobody takes it seriously.

I presume it's inherited from Turbo Pascal, which predates universal adoption of the IEEE standard. Various mainframes have 48 bit reals, and I imagine that Borland thought that if it was good enough for them...

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

440bx

  • Hero Member
  • *****
  • Posts: 3944
Perhaps we should rename "real" to be "trump"
I don't think we should do that, "real' isn't that bad.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

eljo

  • Sr. Member
  • ****
  • Posts: 468
Agreed. Real is anything, but C-ish, cause C does not have such a type.
C does not even have strings, but these C people call everything that smells like a floating point: real. (lest you forgot!)
Only Pascal has a real real type.... ;D >:( with a silly bit count... >:D
Real is a set/type of numbers, the R set. https://en.wikipedia.org/wiki/List_of_types_of_numbers
Quote
Real numbers ({\displaystyle \mathbb {R} }\mathbb {R} ): Numbers that can represent a distance along a line. They can be positive, negative, or zero. All rational numbers are real, but the converse is not true.

while single, double are the accuracy of the datatype.
« Last Edit: February 28, 2020, 04:08:14 pm by eljo »

 

TinyPortal © 2005-2018