Dan Nagle writes:
> I know Fortran processors are supposed to have
> a complex for each real, but a language-lawyer :-)
> might argue that a third real kind is an
> extension, not requiring a corresponding complex.
Yes, I've heard that argument. As a self-certified language
lawyer :-), it doesn't convince me.
Because if the third real kind is claimed to be an extension and thus
not count as one of the kinds fully supported by the processor, then I
think the processor had better conform to 1.4 of the standard, which
requires that the processor "contains the capability to detect and
report the use within a submitted program unit of kind type values
(4.3) not supported by the processor."
I also think that selected_real_kind is non-conforming if it returns
a kind type value that isn't fully supported.
I suppose it would be *possible* for a compiler to conform to the
"letter of the law" in the above matters. It could have a warning for
using the 3rd real kind. And selected_real_kind could avoid returning
it. And there are probably one or two other gotchas like that. But
it would actually require some work to strictly meet those
requirements - just dismissing it all as being an extension isn't
sufficient to make it so.
But although I am a self-appointed language lawyer, I am not a
prosecutor, self-appointed or otherwise. A vendor doesn't have
to "clear" their claims with me. And they don't get penalized
if I disagree with their claims.
To your original question, I'm afraid I don't know a practical
answer. I think my legalese answer would be to make use of
selected_real_kind, which isn't allowed to return a positive value
that couldn't be used in a complex. I'm just afraid that my
legalistic answer is likely to be wrong in practice.
--
Richard Maine
[log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|