-
Notifications
You must be signed in to change notification settings - Fork 87
Error when reading real array value #236
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Currently, JSON-Fortran only supports real(json_rk), dimension(:), allocatable :: rArray and it should work. |
Thanks for the comment. |
@handrake0724 if this resolves your problem, please close the issue. @jacobwilliams I wonder what it would take to support single precision as well. All the get methods seem like they could be implemented with simple wrappers that call the double precision version and then convert to single before returning. There may be some complications with IO, i.e. matching IO precision to that used to put the value in the first place. Another potential difficulty with my proposed approach may be when single precision puts are followed by gets, depending on the specifics of the compilers type conversion/rounding. I don't know if the standard says anything about this. |
@zbeekman @jacobwilliams FWIW it is at least straightforward to allow a single precision (instead of double precision) build of json-fortran by doing: use,intrinsic :: iso_fortran_env, only: real32,real64,int32,logical_kinds
...
#ifdef REAL32
integer,parameter,public :: RK = real32 !! Default real kind [4 bytes]
#else
integer,parameter,public :: RK = real64 !! Default real kind [8 bytes]
#endif in |
Yes adding such a build time option is trivial and should probably be
|
See also #229. I just haven't had time to review it. My preference would be to use the @zbeekman approach, where they are stored as @milancurcic Yes, I like this. I could add this to the code. Then you could use it as-is without having to modify it. What about |
We can use cmake to query for fortran real and integer kinds. It may make On Fri, Nov 18, 2016 at 10:59 AM Jacob Williams notifications@github.com See also #229 #229. I @milancurcic https://github.com/milancurcic Yes, I like this. I could add What about real128? Should that also be a possibility? — |
So, for completeness, something like this: #ifdef REAL32
integer,parameter,public :: RK = real32 !! Default real kind [4 bytes]
#elseif REAL64
integer,parameter,public :: RK = real64 !! Default real kind [8 bytes]
#elseif REAL128
integer,parameter,public :: RK = real128 !! Default real kind [16 bytes]
#else
integer,parameter,public :: RK = real64 !! Default real kind if not specified [8 bytes]
#endif
#ifdef INT8
integer,parameter,public :: IK = int8 !! Default integer kind [1 byte]
#elseif INT16
integer,parameter,public :: IK = int16 !! Default integer kind [2 bytes]
#elseif INT32
integer,parameter,public :: IK = int32 !! Default integer kind [4 bytes]
#elseif INT64
integer,parameter,public :: IK = int64 !! Default integer kind [8 bytes]
#else
integer,parameter,public :: IK = int32 !! Default integer kind if not specified [4 bytes]
#endif |
Yes, and I'll insert come compiler introspection code into the cmake build On Fri, Nov 18, 2016 at 11:15 AM Jacob Williams notifications@github.com
|
Let a jsong file as :
the code is as follows:
I got the following error
There is no matching specific subroutine for this type bound generic subroutine call. [GET]
FYI, my compile environment is visual studio 2015 + intel compiler
The text was updated successfully, but these errors were encountered: