Some experiences with "CASE"
Richard E Maine
Richard.Maine@nasa.gov
Fri May 19 15:23:00 GMT 2006
On May 19, 2006, at 7:45 AM, Philippe Schaffnit wrote:
>
> The first one: GFortran complains on "CASE ( 0, 1, 1 )"
> CASE ( 0, 1, 1 )
> 1 2
> Error: CASE label at (1) overlaps with CASE label at (2)
> OK: this is silly and was only a typo, but still, isn't it over-
> reacting
> a bit?
Well, the code violates a constraint. The standard *REQUIRES* that a
compiler be able to diagnose a violation of a constraint, so I'd say
it was good that gfortran does. If you want to make it a warning, or
even one only diagnosed when the be-picky switch (I forget the exact
switch name) is on, that would be ok, but... it seems to me that
gfortran got it right. You said it was a typo... i.e. and error.
Gfortran caught the error. I'd far prefer it catch typos instead of
ignore them.
> The second: GFortran doesn't seem to like "ç": I have no idea whether
> this is intentional, or just a "local" effect, or...
...[eliding most]
> CHARACTER ( LEN = * ), PARAMETER :: String = "Francais"
...
> CASE ( String, "Français" )
Well, I have essentially zero experience with such characters, so
perhaps I'm completely missing the point. And perhaps it is just that
this got either mistyped or isn't displaying right in my email
reader, but
The literals in those parameter and case statements look different to
me. I would expect them to compare as non-equal, which is what it
looks to me like you were objecting to. Character equality tests are,
by design, what I might call "picky" or perhaps strictly literal.
Just like an upper case "C" compares as different from a lower case
"c", I'd expect a c cedilla (hope I spelled that right; I don't know
how to type one without spending some time to look it up) to compare
as different from an "ordinary" "c".
--
Richard Maine | Good judgment comes from experience;
Richard.Maine@nasa.gov | experience comes from bad judgment.
| -- Mark Twain
More information about the Fortran
mailing list