Maximum number of Switches in a CASE

[jamie]

How deep can I go in a Case statement?

I am porting C code that has Switch statements up to 255 deep, many of them empty but are assigned, could be more I haven't looked at all of the code yet, but I saw that mess and wanted to ensure my efforts were all for not when hitting a limit.

[Curt Carpenter]

Wow.  I am really curious -- can you share anything about the nature of the cases that require so many? 

[Ten_Mile_Hike]

Jamie,

I don't know the answer to your question, but here is a simple workaround that you might utilize if necessary.

Code: Pascal  [Select][+][-]

1. procedure TForm1.Button1Click(Sender: TObject);
2. var
3.   x, z: integer;
4. begin
5.   case x of
6.     1: z := 2;
7.     .
8.     .
9.     255: z := 44;
10.   end;
11.  
12.   case x of
13.     256: z := 27;
14.     .
15.     .
16.     512: z := 101;
17.   end;
18. end;                

[jamie]

Thats an Idea. I never thought of.

I was actually thinking of restructuring the code.

The code is a mess because its old C/C++ and was written in such a way to speed up things.

HMI control management, TAG database, Token values used all over the place via the SWITCHes.

and multiple modules all need to understand the same defines via a form of OPC.

One of the source files is like 6 pages long of just SWITCES

[440bx]

How deep can I go in a Case statement?

In a case statement the compiler has to keep track of the number of entry points (to each case.)

It's extremely unlikely you'd run into a limit associated with that.  There is no inherent reason (other than conserving memory) to have a limit on the number of entry points a case may have.

All this said, only an FPC developer can answer your question with full authority but, I'd be surprised if there was a practical limit.

HTH.

[Thaddy]

When I ported the Castalia parser to FreePascal and tried to add some FPC specific constructs I ran out of space at 255....
That is about the largest case structure I have seen in Pascal.
That particular case loop was machine generated, already at its early origins by Martin Waldenburg
The compiler warns about being too complex if you try to add more.
One way to solve this limit is to use nested cases. I had to do that because there are many more than 255 syntactic elements possible in modern Pascal. Actually someone else that expanded on that code already started with nested case, because Delphi itself has already more posibilities than 255. so I can write with confidence the limit is 256. I am not quite sure a terminating else is counting towards that limit, so it can be one more.
I added the parser, so you can see for yourself. This not my definitive version for FPC, but a working version and stable: It can parse the very complex kol.pas without error.
And it has an exhaustive working case of 256 elements. Try to add one more...

(Oops, posted an older version that still has empty slots, but the principle is the same)

[Eugene Loza]

9999 lines worked for me without issues

[Thaddy]

seems the limit of 256 is no longer there. but is was there at some point.

[jamie]

9999 lines worked for me without issues

That looks promising, I'll will continue to convert, and may write a util to do the conversion.

I tried using H2Pas but it seems that is the wrong tool.

Thanks.

[Joanna]

So there is no known limit on how many ordinal values you can have in a case statement? How about case statements with strings?

[cdbc]

Hi

How about case statements with strings?

Joanna, case statements with string selectors, are just glorified
"if - then - else" statements...
OTOH if you make use of 'IndexText' or its cousin 'IndexStr', then they're limited to whatever 'integer' can count to, on your system 
Regards Benny

[MarkMLl]

It's extremely unlikely you'd run into a limit associated with that.  There is no inherent reason (other than conserving memory) to have a limit on the number of entry points a case may have.

Subject to any inherent limitations on jump table size.

MarkMLl

[Thaddy]

Joanna, ordinal case can be optimized (ordered) string case will not be optimized. This is documented. There is another difference as opposed to TP: ordinal case labels can not overlap, which was possible in TP.



I am rather glad to discover that a previous limitation is no longer there. It gives me the option to improve the parser code for freepascal in a much better, linear, way.

[Joanna]

If there is a case statement that has thousands of choices there is probably a better data structure to implement it.
I wonder what the limitations are for case statements within case statements....

[Curt Carpenter]

Thats an Idea. I never thought of.

I was actually thinking of restructuring the code.

Pity the poor "H" that has to interact with that "M" if a six page switch statement is the only way to make it work