Re: SELECTED_REAL_KIND clarification plse
From: David Ham (d.a.ham_at_citg.tudelft.nl)
Date: Tue, 5 Oct 2004 11:26:33 +0200
On Tue, 05 Oct 2004 20:44:42 +1300
> I'm not suggesting getting rid of SELECTED_*_KIND functions. I
> appreciate that they are very useful, but there are also situations
> where I at least, am concerned with the amount of RAM / storage
> consumed. There are lots of situations where 16bits would provide
> ample space for codes etc (I'm quite happy with definitions in terms
> of bits - thought I hinted at that in my original post, but I will
> obviously have to take more care. I will stick strictly to bits in
> To me, it seems entirely appropriate for a programmer to be concerned
> with resources required where the situation requires. If I can
> minimise storage & keep everything in RAM, then there are big
> benefits. But things get tight when there are multiple fields to hold
> from several million records.
> Equally there are situations where the precision concerns will
> dominate and I am all for retaining direct control over precision.
> But I presume it could lead to very inefficient resource usage - or do
> I have that wrong. eg. if I specify SELECTED_INT_KIND(6) (yuk), then
> will the compiler store these efficiently without large chunks of
> padding between variables?
These are indeed two separate issues. Fortran 2003 might have a
solution for you as far as being able to prescribe integers of specific
storage size - you can use the c interoperability functions and use the
kinds c_int8_t, c_int16_t, c_int32_t and c_int64_t. Of course you hit
the problem any or all of these kinds may not be supported on the given
processor but you always have that: no matter how you specify a type,
you can't have it if your processor doesn't support it.
The selected_*_kind discussion happened here a while back and one
suggestion which seemed popular was to add an argument to
selected_*_kind specifying the base to which the precision and range
arguments are raised. At the moment this is required to be 10 but if you
allow more values then you get a lot more flexibility.
On a related note, I seem to recall seeing on one of the possible
feature lists for the standard after f2003 references to enhanced type
selection. I don't know if the above is what was being referred to,
Finally, a current solution might be found in Dan Nagle's Fortran
Portability Project which provides a way of semi-automatically
generating a module which, among other things, provides constants for
integers and reals of certain sizes. See http://users.erols.com/dnagle/port.html