Re: bug in g95 with character arrays?

Richard Maine wrote:

wim <wim.van.hoydonck@xxxxxxxxx> wrote:

character(len=5), parameter :: test(5) =
["tan","atan2","atan","sin","asin"]
1
Error: Element in character array constructor at (1) has length 5
instead of 3

No, this is not a bug in g95. It is a bug in your code. This was
essentially the first interpretation question I ever asked about f90. I
read the standard and had trouble imagining that things would really
this way because it was so much of a PITA - shades of Pascal - so I
posted a question about it here.
(snip)

Is this another side effect of the rule that the right side
of an assignment (even though it isn't an assignment) doesn't
depend on the type on the left?

My first thought is that it should work for a DATA statement,
but now I am not even sure about that.

(snip)

In f2003, you can explicitly specify the type and type parameters for an
array constructor. This has several effects, one of which is that the
elements in the constructor can have diferent types and type parameters
as long as the needed intrinsic conversion exists.

Thus your example can be written in f2003 as

character(len=5), parameter :: test(5) = &
[character(len=5) :: "tan","atan2","atan","sin","asin"]

Although that looks a bit redundant, it does the job. The apparent
redundancy is because the array constructor does not pick up its type
and type parameters from context. See many, many questions about the
more general case of that principle (most often relating to precision of
reals).

One might think that PARAMETER was different, but it
seems that it isn't.

-- glen

.

Relevant Pages

  • Re: bug in g95 with character arrays?
    ... Element in character array constructor at has length 5 ... this is not a bug in g95. ... I haven't checked for it in g95; ... elements in the constructor can have diferent types and type parameters ...
    (comp.lang.fortran)
  • Re: Strafwerk.
    ... > declaration to require an array constructor on the RHS. ... It is so much the same as in an assignment that the standard doesn't ...
    (comp.lang.fortran)