Prev: object-oriented software (was Re: Features chosen for Fortran2008)
Next: gfortran and "Type/rank mismatch"
From: Mark Morss on 23 Oct 2006 10:20
I've been working with Fortran 95 for a short while. My compiler, g95,
does not appear to accept variable case expressions. For example
CASE(1:k) where k is an integer?

And this be right? It would be simple enough to construct IF blocks to
deal with this, but I thought that CASE constructions were supposed to
facilitate this.

From: highegg on 23 Oct 2006 10:32

Mark Morss wrote:
> I've been working with Fortran 95 for a short while. My compiler, g95,
> does not appear to accept variable case expressions. For example
> CASE(1:k) where k is an integer?
>
> And this be right? It would be simple enough to construct IF blocks to
> deal with this, but I thought that CASE constructions were supposed to
> facilitate this.

I think case selectors must be initialization expressions. So, unless k
is a parameter,
g95 is correct.

From: Gordon Sande on 23 Oct 2006 10:42
On 2006-10-23 11:32:27 -0300, "highegg" <highegg(a)gmail.com> said:

>
> Mark Morss wrote:
>> I've been working with Fortran 95 for a short while. My compiler, g95,
>> does not appear to accept variable case expressions. For example
>> CASE(1:k) where k is an integer?
>>
>> And this be right? It would be simple enough to construct IF blocks to
>> deal with this, but I thought that CASE constructions were supposed to
>> facilitate this.
>
> I think case selectors must be initialization expressions. So, unless k
> is a parameter,
> g95 is correct.

A standard compiler diagnostic is overlapping case values. Which case
should happen then?



From: Mark Morss on 23 Oct 2006 11:28

Gordon Sande wrote:
> On 2006-10-23 11:32:27 -0300, "highegg" <highegg(a)gmail.com> said:
>
> >
> > Mark Morss wrote:
> >> I've been working with Fortran 95 for a short while. My compiler, g95,
> >> does not appear to accept variable case expressions. For example
> >> CASE(1:k) where k is an integer?
> >>
> >> And this be right? It would be simple enough to construct IF blocks to
> >> deal with this, but I thought that CASE constructions were supposed to
> >> facilitate this.
> >
> > I think case selectors must be initialization expressions. So, unless k
> > is a parameter,
> > g95 is correct.
>
> A standard compiler diagnostic is overlapping case values. Which case
> should happen then?

My source (Chapman) says that cases "must be" mutually exclusive,
without saying whether this is a compile-time or a run-time error.
Evidently it is a compile-time error, since Fortran appears to need to
know the case values at compilation time, and will not accept variable
expressions. Thise does appear to limit the utility of the "case"
construction, however.

From: PJH on 26 Oct 2006 06:37
> My source (Chapman) says that cases "must be" mutually exclusive,
> without saying whether this is a compile-time or a run-time error.
> Evidently it is a compile-time error, since Fortran appears to need to
> know the case values at compilation time, and will not accept variable
> expressions. Thise does appear to limit the utility of the "case"
> construction, however.


SELECT CASE is not supposed to be a direct replacement for the IF construct.
It is best considered to be an efficient/elegant way of selecting an item
from an list of literals or constants. It will also work with strings (at
least it does in my compiler - IVF9.1), but I'm not sure if this is
standards compliant. Is a string literal a scalar item?

The constuct works particularly well with enumerated types. Enumerations are
new to F2003, but some of us with a Pascal backgraound have been using
manually generated enumerated constants for many years. It is a great shame
that proper enumeration support was not introduced in F90 along with the
SELECT CASE construct. In fact even the F2003 enumerations are rather
half-hearted compared with Pascal type safe enumerators - I guess the
standards committee is not particularly enthusiastic about them. This has
been discussed several times before on this board and I don't particularly
want to reignite the debate.

Paul Holden


 |  Next  |  Last
Pages: 1 2
Prev: object-oriented software (was Re: Features chosen for Fortran2008)
Next: gfortran and "Type/rank mismatch"