Van Snyder wrote:
> Malcolm Cohen wrote:
> The problem with writing libraries using SELECTED_REAL_KIND instead of
> REAL and DOUBLE PRECISION is that they might have portability problems
> in the area of generic resolution. If one procedure has arguments with
> SELECTED_REAL_KIND(6), and another has SELECTED_REAL_KIND(12), you probably
> get default REAL and default DOUBLE PRECISION, respectively, on 32-bit
> platforms, but you probably get default REAL for both of them on 64-bit
> platforms.
Not if you use Walt Brainerd's idea of
selected_real_kind ( precision (1.0) + 1)
which should give a different kind from that for 1.0.
> Although each procedure compiles in the latter case, generic
> resolution fails -- the library won't even compile if it contains the
> generic interface blocks to glue the two procedures together. If you "lift"
> the generic interface blocks out of the library into your code, then your
> code won't compile. The alternative is manual selection of which sub-
> library to use. To solve this problem, Fortran really does need a method
> to create a _new_ type that may have representation and operations identical
> to an existing type. The type alias facility introduced to support C
> interoperability doesn't create a new type, and therefore doesn't help
> with this problem.
>
> If you know a priori that you're only going to use platforms that support
> a precision greater than DOUBLE PRECISION, you can probably get away with
> using default REAL, default DOUBLE PRECISION, and
> REAL(SELECTED_REAL_KIND(DIGITS(0.0d0)+1)).
DIGITS? DIGITS gives the number of binary digits.
PRECISION is probably what you mean, which returns the
number of decimal digits.
> Best regards,
> Van Snyder
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|