For the code segment below I get the errors listed. An error is not generated for "blank" as a label, so it seems that indexing a constant array of char confuses the compiler. Help would be appreciated.
--Chris Ferrall
fmopt_client.pas:212: `case' label does not reduce to a constant of ordinal type fmopt_client.pas:213: `case' label does not reduce to a constant of ordinal type fmopt_client.pas:214: `case' label does not reduce to a constant of ordinal type
type integer_options = (max_untyp,mxstarts,nfuncmax);
const blank = ' '; imn : array[integer_options] of char = ('u','r','n'); var lt : char;
... case lt of imn[mxstarts] : read(x_file,iopts[mxstarts]); imn[nfuncmax] : read(x_file,iopts[nfuncmax]); imn[max_untyp] : read(x_file,iopts[max_untyp]); eooptln : readln(x_file); blank : ; otherwise writeln('invalid integer option ',lt); end;
Christopher Ferrall wrote:
For the code segment below I get the errors listed. An error is not generated for "blank" as a label, so it seems that indexing a constant array of char confuses the compiler. Help would be appreciated.
Yes, for compatibility to a stupid BP feature, GPC treats typed constants like variables.
However, I'm not sure if EP actually allows such structured constants in a `case' statement. Anyone knows? (And if it does, it should probably be an EP style constant (which GPC doesn't support completely yet, AFAIK), not a BP style constant like you use.)
Anyway, a series of plain constants should work in any case.
Frank
On 15 Jun 2001, at 18:10, Frank Heckenbach wrote:
However, I'm not sure if EP actually allows such structured constants in a `case' statement. Anyone knows?
The EP standard requires a "constant-expression" for the case-constant in a case-range in a case-constant-list. A constant-expression is an "expression" that "...shall be nonvarying and shall not contain a discriminant-identifier" (6.8.2). So the use of:
case lt of imn[mxstarts] : ...
...should be legal, as "imn[mxstarts]" is a "constant-access", assuming:
type integer_options = (max_untyp, mxstarts, nfuncmax); array_options = array [integer_options] of char;
const imn = array_options [max_untyp : 'u'; mxstarts : 'r'; nfuncmax : 'n'];
var lt : char;
This should be semantically equivalent to:
case lt of 'r' : ...
...it should probably be an EP style constant (which GPC doesn't support completely yet, AFAIK)...
The first item under Section 11.2.2 of the GPC Manual lists "ISO structured constants" as yet to be implemented, and the above code fails to compile, so I believe that you are correct. :-(
-- Dave
J. David Bryan wrote:
On 15 Jun 2001, at 18:10, Frank Heckenbach wrote:
However, I'm not sure if EP actually allows such structured constants in a `case' statement. Anyone knows?
The EP standard requires a "constant-expression" for the case-constant in a case-range in a case-constant-list. A constant-expression is an "expression" that "...shall be nonvarying and shall not contain a discriminant-identifier" (6.8.2). So the use of:
case lt of imn[mxstarts] : ...
...should be legal, as "imn[mxstarts]" is a "constant-access", assuming:
type integer_options = (max_untyp, mxstarts, nfuncmax); array_options = array [integer_options] of char;
const imn = array_options [max_untyp : 'u'; mxstarts : 'r'; nfuncmax : 'n'];
var lt : char;
This should be semantically equivalent to:
case lt of 'r' : ...
...it should probably be an EP style constant (which GPC doesn't support completely yet, AFAIK)...
The first item under Section 11.2.2 of the GPC Manual lists "ISO structured constants" as yet to be implemented, and the above code fails to compile, so I believe that you are correct. :-(
And the above requirement seems to make it even more difficult to implement them in the future. :-(
Frank
-
Christopher Ferrall -
Frank Heckenbach -
J. David Bryan