Clive Page said:
>1. You can't create a generic interface to two routines which differ only
>in string length.
Indeed not. This would be ambiguous, since it is allowable to pass long
actual string arguments to short string dummy arguments.
Moreover, string length is not generally known at compile-time, so the
compiler would not know which routine to call anyway!
>Some years ago I created a group of routines to handle
>a tree-like structure, and eventually expanded it to cover integer, real,
>double precision, and string data types, with a user-friendly generic
>interface for insert/delete/etc. The string type was character(len=12)
>but now I want to add character(len=32). I _could_ change the whole thing
>to the longer length, but the inefficiency of shuffling about 32
>characters in cases when I only want 12 of them makes me a bit unhappy.
Why not package up the 32-length characters into a derived type?
TYPE s32
CHARACTER*32 value
END TYPE
Then instead of doing
CALL sub('1234567890xxxx ')
do
CALL sub(s32('1234567890xxxx'))
etc.
>2. The possibilities for dynamic string lengths in subprograms are very
>limited.
In a subprogram, a character length can be anything specifiable by a
specification expression - which includes (pure) user-defined functions.
Seems not very limited to me.
>In particular strings in data structures (derived data types)
>have to have their length fixed at compile-time, which I find a serious
>restriction.
Well now, that is indeed a restriction.
The only way in F90 to have completely dynamic amounts of character data is
to use pointer components. Ditto F95.
>The only solution I have come up with is to have two
Hmm, you say "only solution" and then mention 3 different ones!
>pointers, and only allocate and use one of them at a time, e.g.
>
> type :: mytype
> character(len=12), pointer :: small(:) ! use one or other
> character(len=32), pointer :: medium(:)
> end type mytype
>
>There is presumably a small overhead on space from the unused pointer
>array, but nothing to worry about.
>
>An alternative would be to convert each string into an array, so as a
>pointer component the length could be fully dynamic. But this means my
>simple 1-d array turns into a 2-d array,
Actually, you could have a simple 1-d array of a derived type which itself
has a 1-d pointer array component.
> and the code difference between
>the character and the non-character versions of the routines diverge
>even further. It also means I need to use TRANSFER functions each way to
>pack and unpack the pointer components from arguments of the routine, and
>these have a reputation of being _extremely_ inefficient on many
>compilers.
You could use array constructors, which are probably equally inefficient
on many compilers.
e.g. something like
TYPE(mytype) x(:)
CHARACTER(*) arg(:)
...
DO i=1,n
x%chval(:,i) = (/ (arg(i)(j:j),j=1,SIZE(x%chval,2)) /)
END DO
>I _could_ use the ISO_VARYING_STRING module, but there are reports of
>memory leaks in some circumstances, and I suspect I'd find them hard to
>avoid.
You could use the allocatable components version, which does not suffer
from these memory leaks.
>Has anyone else come across these problems, or have any ideas? I haven't
>seen much to suggest that F2002 is going to offer any improvement, but
>maybe I have missed something.
Allocatable string length would seem to do everything you want.
E.g. For an array of strings all the same length
TYPE mytype
CHARACTER(:),ALLOCATABLE :: charray(:)
END TYPE
TYPE(mytype) x
...
ALLOCATE(CHARACTER(length) :: x%charray(arraysize))
For an array of different-length strings
TYPE string
CHARACTER(:),ALLOCATABLE :: value
END TYPE
TYPE mytype
TYPE(string),ALLOCATABLE :: charray
END TYPE
TYPE(mytype) x
...
ALLOCATE(x%charray(arraysize))
DO i=1,arraysize
ALLOCATE(CHARACTER(length(i)) :: x%charray(i)%value)
END DO
Cheers,
--
...........................Malcolm Cohen, NAG Ltd., Oxford, U.K.
([log in to unmask])
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
