Hi Alan,
By using the fixed number 4 you make a classical mistake: the kind number is
not related to the number of bytes that a value of the given kind and type
occupies in memory. For instance: years ago (before Fortran 90 compilers were
common enough) I used a NEC computer that had two different types of
single-precision reals, one native, fast but not portable, and one conforming
to IEEE. They both occupied 4 bytes of memory. The kind system has been
explicitly defined to distinguish such formats.
You do have a point though - the types on the Fortran side should match the
types on the C side. Therefore I suggest using:
use, intrinsic :: iso_c_binding, only: c_int32_t
integer, parameter :: plint = c_int32_t
For the logical values, there is an intrinsic problem:
C uses integer values to represent logical (boolean) data, being 0 for false
and not-0 for true, but Fortran has a separate logical type that may or may not
coincide with C's scheme. (Actually, some compilers use -1 as true and 0 as
false, while others merely interpret the first bit, IIRC)
To circumvent that, we have in sfstubs95.f90 the private functions
convert_to_int and convert_to_log which, as the name implies, convert from
Fortran logicals to C integers being interpreted as logicals and vice versa.
Given the above terse description of the kind system, there is no compelling
reason for the compiler to use the same kind numbers for integers and logicals.
So: "integer, parameter :: plbool = plint" may very well fail.
Since we do not rely on a magical match between C's booleans and Fortran's
logical, we can simply use the default kind, implicitly or explicitly, for our
Fortran logical data.
Regards,
Arjen
> -----Original Message-----
> From: Alan W. Irwin [mailto:[email protected]]
> Sent: Tuesday, September 09, 2014 7:55 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: integer and logical precision for our Fortran bindings and examples
>
> On 2014-09-09 06:44-0000 Arjen Markus wrote:
>
> > As for the kinds of integers and logicals, I suggest:
> >
> >
> >
> > integer, parameter :: plint = kind(0) ! The default integer, which is in
> > 99% of the
> cases a 4-bytes integer
> > integer, parameter :: plbool = kind(.false.)
>
> These are indefinite types, but note the C equivalents (which these fortran
> types are
> supposed to match exactly) are exact precision in include/plplot.h rather than
> indefinite precision:
>
> typedef int32_t PLINT;
> typedef PLINT PLBOOL;
>
> So isn't
>
> integer, parameter :: plint = 4
> integer, parameter :: plbool = 4
>
> the exactly correct thing to do instead of the indefinite types you have
> suggested
> using above?
>
> If you are convinced now by this "equivalent to what we do in C"
> argument that the above two explicit definitions of plint=4 and
> plbool=4 should go into bindings/f95/plflt.inc.in, then my plan is to make
> that change,
> then sed-edit all our Fortran binding and examples code to transform
>
> integer ==> integer(kind=plint)
> logical ==> logical(kind=plbool)
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation for
> stellar interiors (freeeos.sf.net); the Time Ephemerides project
> (timeephem.sf.net);
> PLplot scientific plotting software package (plplot.sf.net); the libLASi
> project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the
> Linux Brochure
> Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged information. If you are not the intended
recipient please notify the sender immediately and destroy this message.
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The
Netherlands, Commercial Registration Number 41146461, is not liable in any way
whatsoever for consequences and/or damages resulting from the improper,
incomplete and untimely dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
