Re: Reading complex multidimensionalarrays from C

e p chandler <epc8@xxxxxxxx> wrote:

You
are not guaranteed that a particular compiler supports what might be
declared as (non-standard) DOUBLE COMPLEX or COMPLEX*16 or a type of
complex using kinds).

Yes, support of double precision complex is guaranteed by the standard
as of f90. (The code already uses an f90 syntax and the mentioned
compilers are f90/f95 ones). You do have to use the f90 kind syntax to
declare them; the syntax forms "double cimplex" and complex*16 were not
standardized, but the functionality of double precision complex was.

In fact, the f90 standard requires that *EVERY* real kind have a
corresponding complex kind. I have seen vendors try to rationalize that
they can support a quad precision real without also supporting a quad
precision complex, but I don't think that the rationalizations hold up.
The usual rationalization claims that the quad precision real is an
extension and thus that the requirement for a corresonding complex
doesn't apply.

However, I don't buy that rationalization because I don't think such
vendors actually implement quad precision real in a way that counts as
an extension. An extension can't make standard conforming code invalid;
if that happens, the compiler is violating the standard rather than
extending it. The distinction is critical.

For example, selected_real_kind is required to return either a valid
kind number or a negative error indication. Any positive number returned
from it is supposed to be valid. I claim it is a compiler violation of
the standard - not an extension - if a positive value returned from
selected_real_kind can't be used as a complex kind value.

It might be possible to do a quad precision real in a way that counted
as an extension and had no corresponding quad complex, but I bet that's
not what any vendors do.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
.

Relevant Pages

  • Re: COBOL "non-myth" confirmed - Index and subscripts (MF on Windows)
    ... number of multiplys and optimization may be just the same. ... I'll wager 100US it shows the offset from the beginning of the table on my compiler, ... The 02 Standard allows one to define native types with BINARY-SHORT and BINARY-LONG. ... allow that extension if the appropriate flags are on, ...
    (comp.lang.cobol)
  • Re: Multi precision floating point
    ... extension is a string function called strdup. ... If it compiles on every ideal, conforming C compiler then it requires ... I believe that one common technique for using the features that you correctly point out are not part of standard C is to wrap them into a small part of your program, and write the main part in Standard C which calls a wrapper function when it wants to use a nonstandard feature. ...
    (comp.lang.c)
  • Re: Multi precision floating point
    ... language extension. ... the offsetof() macro was provided by the quote that I have included ... The standard library macro defined in, ... compiler accepts a program with a syntax error or a constraint violation, ...
    (comp.lang.c)
  • Re: creating directories on the fly
    ... system is not a standard intrinsic subroutine. ... > Tools" that comes with the compiler. ... Although the SYSTEM subroutine does not belong to the Fortran ... i don't get an indication that I'm using an extension... ...
    (comp.lang.fortran)
  • Re: Is C99 the final C? (some suggestions)
    ... > that someone will try compile their stuff on an old compiler. ... > because the ANSI standard obsoleted them, and everyone picked up the ANSI ... fixed by using another language. ... >>are multiplying two expressions of the widest type supported by your ...
    (comp.lang.c)