Recent

Author Topic: Problems with case statement [SOLVED]  (Read 1163 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 8032
Re: Problems with case statement [SOLVED]
« Reply #15 on: September 16, 2024, 10:49:15 pm »
No, there is no $mode at the top of my file. The only significant difference between my code and yours is, possibly, that mine is being compiled as a Lazarus project, with the source code being held in the `Search_Replace.lpr` file. Otherwise my code is exactly as in the message labelled "The final working code...".

And the insignificant differences? :-)

If you manage to get anything like that happen again then freeze it: zip the entire directory tree without deleting anything. My suspicion is that you'd found a way to trigger a subtle problem- and I'm not sure whether this is the IDE or compiler- where something was not recompiled when it should have been and having the various intermediate files might enable the developers (poor dears!) to track it down.

But I would emphasise that this is not common, the only time that I've seen it was when there was a combination of conditional compilation and include files.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Curt Carpenter

  • Hero Member
  • *****
  • Posts: 564
Re: Problems with case statement [SOLVED]
« Reply #16 on: September 16, 2024, 10:58:36 pm »
Line 60 in your console app is different than line 18 in your original post if it matters.


carl_caulkett

  • Hero Member
  • *****
  • Posts: 649
Re: Problems with case statement [SOLVED]
« Reply #17 on: September 16, 2024, 11:23:58 pm »
Thanks! It's okay. There were quite a few improvements over the original post, eg. the use of +=.
"It builds... ship it!"

carl_caulkett

  • Hero Member
  • *****
  • Posts: 649
Re: Problems with case statement [SOLVED]
« Reply #18 on: September 16, 2024, 11:28:40 pm »
If you manage to get anything like that happen again then freeze it: zip the entire directory tree without deleting anything. My suspicion is that you'd found a way to trigger a subtle problem- and I'm not sure whether this is the IDE or compiler- where something was not recompiled when it should have been and having the various intermediate files might enable the developers (poor dears!) to track it down.

Yes, you're quite right, I should have kept a frozen copy. I was more concerned with getting it working, but I appreciate that capturing these, thankfully rare, glitches is the only way they're going to get fixed.
"It builds... ship it!"

Thaddy

  • Hero Member
  • *****
  • Posts: 16184
  • Censorship about opinions does not belong here.
Re: Problems with case statement [SOLVED]
« Reply #19 on: September 17, 2024, 10:43:31 am »
Thanks! It's okay. There were quite a few improvements over the original post, eg. the use of +=.
Almost all core developers regret that they ever implemented it and it is prone to errors. Do Not Use.
It is also incomplete in its implementation: it does not allow e.g =+
This advice is not by me, but by the core developers.
If I smell bad code it usually is bad code and that includes my own code.

MarkMLl

  • Hero Member
  • *****
  • Posts: 8032
Re: Problems with case statement [SOLVED]
« Reply #20 on: September 17, 2024, 11:12:35 am »
Almost all core developers regret that they ever implemented it and it is prone to errors. Do Not Use.
It is also incomplete in its implementation: it does not allow e.g =+
This advice is not by me, but by the core developers.

I don't like criticising the core team in public, but if they are aware of problems with specific use cases then those should result in compilation errors or warnings.

I've seen far too many idioms which are assumed to exist by people with experience in other languages rejected because "they aren't Pascal". It's all very well refusing to implement something which results in ambiguous syntax or unreliable semantics (notably, ++ etc.), but in the vast majority of cases += is applied to a simple scalar and anybody who doesn't like that should have their objections properly documented.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
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: 16184
  • Censorship about opinions does not belong here.
Re: Problems with case statement [SOLVED]
« Reply #21 on: September 17, 2024, 11:32:46 am »
Mark, if they did not implemented it by accident, there would be no questions.
One of those things that are hard to withdraw. I am sure you experienced similar in your carreer.
Some users still insist on it, against all warnings over the years and this is a non-feature that is the least likely to get much attention for improvement. Duely so.
If I smell bad code it usually is bad code and that includes my own code.

carl_caulkett

  • Hero Member
  • *****
  • Posts: 649
Re: Problems with case statement [SOLVED]
« Reply #22 on: September 17, 2024, 12:07:51 pm »
Thanks! It's okay. There were quite a few improvements over the original post, eg. the use of +=.
Almost all core developers regret that they ever implemented it and it is prone to errors. Do Not Use.
It is also incomplete in its implementation: it does not allow e.g =+
This advice is not by me, but by the core developers.

Yikes  :o

I'll remove them forthwith...
"It builds... ship it!"

alpine

  • Hero Member
  • *****
  • Posts: 1302
Re: Problems with case statement [SOLVED]
« Reply #23 on: September 17, 2024, 02:21:56 pm »
Sorry for being off topic ...

I've seen far too many idioms which are assumed to exist by people with experience in other languages rejected because "they aren't Pascal". It's all very well refusing to implement something which results in ambiguous syntax or unreliable semantics (notably, ++ etc.), but in the vast majority of cases += is applied to a simple scalar and anybody who doesn't like that should have their objections properly documented.
Isn't that the same as saying that IfThen(Boolean,Arg1,Arg2) can be used in exchange for the ternary operator as it will be applied only to constant/simple Arg1,Arg2 expressions?
 
Just to refresh your memory a bit:
https://forum.lazarus.freepascal.org/index.php/topic,55338.msg411546.html#msg411546
https://gitlab.com/freepascal.org/fpc/source/-/issues/39206

Consider:
Code: Pascal  [Select][+][-]
  1. function PostIncInl(var I: Integer): Integer; inline;
  2. begin
  3.   Result := I; Inc(I);
  4. end;
  5.  
  6. function PostInc(var I: Integer): Integer;
  7. begin
  8.   Result := I; Inc(I);
  9. end;
  10.  
  11. var
  12.   A: array of Integer = (0, 0, 0, 0);
  13.   B: array of Integer = (0, 0, 0, 0);
  14.   I: Integer = 0;
  15. begin
  16.   A[PostInc(I)] += 1; // A[I++] += 1;
  17.   A[PostInc(I)] += 1; // A[I++] += 1;
  18.   I := 0;
  19.   B[PostIncInl(I)] += 1; // B[I++] += 1;
  20.   B[PostIncInl(I)] += 1; // B[I++] += 1;
  21.   // A = (1, 0, 1, 0)
  22.   // B = (0, 1, 0, 1)
  23. end.
Can you see the effect of a single inline directive?

Lazarus 2.2.4 (rev lazarus_2_2_4) FPC 3.2.2 x86_64-linux-gtk2
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

MarkMLl

  • Hero Member
  • *****
  • Posts: 8032
Re: Problems with case statement [SOLVED]
« Reply #24 on: September 17, 2024, 03:02:33 pm »
Isn't that the same as saying that IfThen(Boolean,Arg1,Arg2) can be used in exchange for the ternary operator as it will be applied only to constant/simple Arg1,Arg2 expressions?

No, it's the same as saying that the compiler will reject any attempt to use it for other than simple expressions.

I believe that IfThen()'s behaviour is well documented, but in any event it can be inferred from the fact that it's a standard function which can be expected to evaluate its parameters in the same way as any other function.

The developers have- at various times in the forum etc.- told us why they don't like += . However I do not believe that these objections have been marshalled into any of the manuals, and there is definitely nothing that says "Don't use these" (which could include a deprecation or portability marker).

"In addition to the standard Pascal assignment operator (:=), which simply replaces the value of the variable with the value resulting from the expression on the right of the := operator, Free Pascal supports some C-style constructions ... These constructions are just for typing convenience, they don’t generate different code."

In what way does that constitute a "there are conditions under which this fails" warning?

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018