- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
On using
routineX (line)
use numnerical_libraries, only: IIDEX
character(*), intent(in):: line
N=IIDEX(line, 'Hello')
...
I get the compiler error:
Error: If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a subs
none of the inputs to IIDEX are arrays, or are they? I treied Line(:) but not good.
any ideas? else is there another case insensitive INDEX function?
Tim
routineX (line)
use numnerical_libraries, only: IIDEX
character(*), intent(in):: line
N=IIDEX(line, 'Hello')
...
I get the compiler error:
Error: If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a subs
none of the inputs to IIDEX are arrays, or are they? I treied Line(:) but not good.
any ideas? else is there another case insensitive INDEX function?
Tim
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, here's the interface for IIDEX from NUMERICAL_LIBRARIES.F90:
So it is indeed an array in the interface, but the interface is wrong, if I look up the documentation on IIDEX. It seems there are a few others like this, where some programmer at VNI thought that the above declaration was the same as character(len=*).
You could create your own interface for IIDEX and rename the one from NUMERICAL_LIBRARIES to be something else, so as to not conflict. That's what I would recommend.
Steve
integer function iidex (chrstr, key) character, dimension(*), intent(in) :: chrstr character, dimension(*), intent(in) :: key end function
So it is indeed an array in the interface, but the interface is wrong, if I look up the documentation on IIDEX. It seems there are a few others like this, where some programmer at VNI thought that the above declaration was the same as character(len=*).
You could create your own interface for IIDEX and rename the one from NUMERICAL_LIBRARIES to be something else, so as to not conflict. That's what I would recommend.
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, those airheads!
The same problem exists with IICSR, and likely other string manipulation routines.
An easy solution seems to be to feed the args to trim(), e.g.
n=IIDEX(trim(a),trim(b))
I can only guess how this might address the problem.
tim
The same problem exists with IICSR, and likely other string manipulation routines.
An easy solution seems to be to feed the args to trim(), e.g.
n=IIDEX(trim(a),trim(b))
I can only guess how this might address the problem.
tim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I will make sure that this error is corrected for the 6.6C update (yes, still in the works.) We get the IMSL modules precompiled from VNI, but I went ahead and edited them to remove this class of error as well as a few others I observed.
I'll upload the corrected interfaces to our FTP site on Monday and provide a pointer here so that folks can try them.
Steve
I'll upload the corrected interfaces to our FTP site on Monday and provide a pointer here so that folks can try them.
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It looks as if history repeats... similar error existed on several places in early DFWIN versions (probably inherited from Microsoft). For one, I recall that WIN32_FIND_DATA had file name declared as CHARACTER:: cFileName(MAX_PATH) -- it was a real PITA to do anything with it :-(.
Jugoslav
Jugoslav
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page