A couple of times recently I have been thwarted in what I want to do by
Fortran95's lack of flexibility in the character type. I'm aware that the
strings of C/C++ are even worse - a high proportion of hacker attacks and
internet insecurities seem to have C buffer overflows as the root cause,
but still I wonder if I'm missing something in Fortran, or whether F2002
will be any better.
1. You can't create a generic interface to two routines which differ only
in string length. 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.
2. The possibilities for dynamic string lengths in subprograms are very
limited. In particular strings in data structures (derived data types)
have to have their length fixed at compile-time, which I find a serious
restriction. The only solution I have come up with is to have two
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, 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.
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.
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.
--
Clive Page,
Dept of Physics & Astronomy,
University of Leicester.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|