Fortran - F2003 and varying strings

Author

F2003 and varying strings

David Frank

2004-10-27, 8:56 am

Does F2003 dynamic reallocation extend to character strings thus obsoleting
any of the various monstrous varying string add-ins?

e.g.

character(:),allocatable :: string
string = '1234'
write (*,*) len(string), string ! outputs: 41234 ?

string = 'abcdef'
write (*,*) len(string), string ! outputs: 6abcdef ?
end program

IOW, what does a independent varying strings package provide that
above capability (if it exists) does not?

Rich Townsend

2004-10-27, 8:56 am

James Giles

2004-10-27, 3:58 pm

David Frank wrote:
> Does F2003 dynamic reallocation extend to character strings thus obsoleting
> any of the various monstrous varying string add-ins?
>
> e.g.
>
> character(:),allocatable :: string
> string = '1234'
> write (*,*) len(string), string ! outputs: 41234 ?
>
> string = 'abcdef'
> write (*,*) len(string), string ! outputs: 6abcdef ?
> end program
>
> IOW, what does a independent varying strings package provide that
> above capability (if it exists) does not?

Well, one thing that the varying strings supplementary standard
has is GET. The procedure reads all the data on an input record
into a single varying string no matter how long the record is.
If the new allocatable strings in F2003 do this with ordinary
I/O statements I can't find any mention of it.

So, given the declaration in your example, suppose the first
record of the input is:

zyxwvutsrqpon

With the end of the record following the 'n'. Then the following
read should leave STRING with a value of ' zyxwvutsrqpon' and
LEN(STRING) should be 16 (includes the 3 leading spaces):

read (*,*) string ! read whole record

I don't think F2003 does this though. It's something I would
use a lot.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

David Frank

2004-10-28, 8:57 am

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:0AQfd.34092$OD2.23087@bgtnsc05-news.ops.worldnet.att.net...
> David Frank wrote:
>
> Well, one thing that the varying strings supplementary standard
> has is GET. The procedure reads all the data on an input record
> into a single varying string no matter how long the record is.
> If the new allocatable strings in F2003 do this with ordinary
> I/O statements I can't find any mention of it.
>
> So, given the declaration in your example, suppose the first
> record of the input is:
>
> zyxwvutsrqpon
>
> With the end of the record following the 'n'. Then the following
> read should leave STRING with a value of ' zyxwvutsrqpon' and
> LEN(STRING) should be 16 (includes the 3 leading spaces):
>
> read (*,*) string ! read whole record
>
> I don't think F2003 does this though. It's something I would
> use a lot.
>
> --
> J. Giles
>

Bypassing whether reallocation can happen during a read string,
my primary question was whether reallocation can happen when longer string
is assigned to a string whose len is declared allocatable.
IMO, this would be the majority usage of varying strings.

Other F2003 gurus have an opinion, dick hendrickson ??

Richard E Maine

2004-10-28, 3:59 pm

"James Giles" <jamesgiles@worldnet.att.net> writes:

> ... Then the following
> read should leave STRING with a value of ' zyxwvutsrqpon' and
> LEN(STRING) should be 16 (includes the 3 leading spaces):
>
> read (*,*) string ! read whole record
>
> I don't think F2003 does this though. It's something I would
> use a lot.

No it doesn't do that, and I'd find it quirkily inconsistent in the
treatment of blanks. I could understand automatically allocating the
length of string (the length being allocatable in the elided
declaration). In fact, that makes enough sense to me that I find
myself half wondering why it doesn't work that way and whether I've
overlooked something that says it does (but I don't think I have).
Though we also don't auto-allocate arrays in read statements (and I
can see reasons why auto-allocatig arrays just wouldn't work unless we
restricted it to some very special cases - common cases, perhaps, but
very special in form.)

But I just can't see special-casing the blank treatment in this way.
I don't see why blanks would be treated differently depending on
whether string was allocatable or not.

I agree that it would be useful to have a facility to read a whole line
into an allocatable string, automatically allocating the corresponding
length. I just don't agree that this fits very well under list-directed
formatting. I don't see the fit at all.

One could presumably write a subroutine to do this, using
non-advancing I/O "under the covers". Shouldn't be hard. Admittedly,
one couldn't easily mimic all the optional specifiers that can appear
in READ statements.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

James Giles

2004-10-28, 3:59 pm

Richard E Maine wrote:
> "James Giles" <jamesgiles@worldnet.att.net> writes:
>

[color=darkred]
> But I just can't see special-casing the blank treatment in this way.
> I don't see why blanks would be treated differently depending on
> whether string was allocatable or not.

Oh, I see. Yes, I was remiss in my example. You are right, in this
case the leading spaces should not be in the string. I usually give the
example as:

read(*,"(a)") string ! reads the whole record

In list-directed you are right that spaces should remain delimiters
if no explicit delimiters are present.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

James Giles

2004-10-28, 3:59 pm

David Frank wrote:
....
> Bypassing whether reallocation can happen during a read string,
> my primary question was whether reallocation can happen when longer string
> is assigned to a string whose len is declared allocatable.
> IMO, this would be the majority usage of varying strings.

The answer is yes. There are explicit examples in the standard
document:

NOTE 7.35
For example, given the declaration

CHARACTER(:),ALLOCATABLE :: NAME

then after the assignment statement

NAME = ’Dr. ’//FIRST_NAME//’ ’//SURNAME

NAME will have the length LEN(FIRST NAME)+LEN(SURNAME)+5,
even if it had previously been unallocated, or allocated with a different
length. However, for the assignment statement

NAME(:) = ’Dr. ’//FIRST_NAME//’ ’//SURNAME

NAME must already be allocated at the time of the assignment; the
assigned value is truncated or blank padded to the previously allocated
length of NAME.

It is to be assumed that future implementations of the varying-string
supplementary standard will use allocatable strings as their internal
implementation of the data. In fact, if we had type-aliasing, the
varying-string type could be just an alias for allocatable strings
and the rest of the varying-string implementation would be just
an addition of the new procedures that are "intrinsic" to that
standard.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

glen herrmannsfeldt

2004-10-28, 3:59 pm

James Giles wrote:

> David Frank wrote:
[color=darkred]

The Java string model reallocates at just about every string
operation. Reallocation is, in general, much less efficient
than copying data into an existing string, and Java has the
StringBuffer for that. The string concatenation operation
is defined to be implemented as:

Create a new StringBuffer.
Copy the first string into the StringBuffer.
Append the second to the StringBuffer.
Convert the StringBuffer to a String.
Store a reference to the new String in the destination
Object reference variable (pointer).
The previous string may now be available for the garbage collector.

It is convenient not to have to worry about string bounds, or
allocation and deallocation, but there is overhead behind it.

-- glen

Richard E Maine

2004-10-28, 3:59 pm

"James Giles" <jamesgiles@worldnet.att.net> writes:

[where string is a character variable of allocatable length).

> read(*,"(a)") string ! reads the whole record

That I'd agree would have been a neat feature. Likely to be
a compatibility issue to add it in exactly that form post f2003,
now that it is legal with a different meaning.

It wasn't legal in f95 because there was no such thing as allocatable
length characters at all, which is why the assignment stuff could be
added without breaking any existing standard code. Presumably it
could also have been done in a read... but it wasn't. Not sure why,
but possibly because the concept of "long enough to go to the end of
the record" would have to have been added, along with some related
special-case stuff. For example, I presume that formats like
"(f10.3,a)" would also be fine with allocatable length chars; if they
aren't, one would have to explain the special-casing. On the
other hand, I can't figure out how "(a,f10.3)" could reasoanbly make
sense if the "a" part was defined to read to the end of the record.
All solvable, I'm sure, but sounds like it might have required
solving; maybe that's why it wasn't done. Don't really recall,
though, so don't cite me as saying that this *WAS* the reason,
just that it sounds plausible as one.

So... purely my personal speculation... to have much chance of
adding such a feature now, you'd have to do something slightly different
in the syntax. Maybe a slight variant on the "a" descriptor. I'm
sure something could be done... haven't actually tried to think up
a specific idea on it.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

glen herrmannsfeldt

2004-10-28, 3:59 pm

Richard E Maine wrote:

(snip)

> That I'd agree would have been a neat feature. Likely to be
> a compatibility issue to add it in exactly that form post f2003,
> now that it is legal with a different meaning.

(snip)

> So... purely my personal speculation... to have much chance of
> adding such a feature now, you'd have to do something slightly different
> in the syntax. Maybe a slight variant on the "a" descriptor. I'm
> sure something could be done... haven't actually tried to think up
> a specific idea on it.

For comparison purpose only, PL/I supplies the ability to read an
entire record into a varying length character variable as part of
RECORD oriented I/O. Record I/O is somewhat related to Fortran
UNFORMATTED I/O in that it is not done with coversions between
internal and printable representations.

It might be that a single variable length character string in
a record I/O statement is a special case.

-- glen

James Giles

2004-10-28, 8:56 pm

glen herrmannsfeldt wrote:
> James Giles wrote:
>
>
>
> The Java string model reallocates at just about every string
> operation. Reallocation is, in general, much less efficient
> than copying data into an existing string, and Java has the
> StringBuffer for that. [...]

Of course implementations don't actually *have* to reallocate
on every string assignment. I've seen implementations of the
Fortran varying string feature that reallocate even when the
new data is the same length as the variable already contains.

But, you could have the implementation allocate only in
multiples of a specific size (most memory managers actually
only allocate on certain address multiples anyway: for cache
reasons or other reasons having to do with memory efficiency).
Then you reallocate only when necessary as the data grows -
and possibly not at all when the new data is smaller. The
actually allocated space can be different from the LENgth
reported by the intrinsic function, it always reports only the
length of the data.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

robin

2004-10-29, 3:58 am

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: >
>
> For comparison purpose only, PL/I supplies the ability to read an
> entire record into a varying length character variable as part of
> RECORD oriented I/O. Record I/O is somewhat related to Fortran
> UNFORMATTED I/O in that it is not done with coversions between
> internal and printable representations.

PL/I can also read in an entire record into a varying-length
character string via stream I/O (i.e., formatted I/O).

> It might be that a single variable length character string in
> a record I/O statement is a special case.
>
> -- glen

David Frank

2004-10-30, 3:56 am

James Giles

2004-10-30, 3:56 am

David Frank wrote:
....
> I would expect a user VGETS function can be easily coded
> with F2003 syntax, yes/no ?
>
> ! ------------------------------------------
> program no_supplementary_varying_string ! needed in F2003
> character(:),allocatable :: string ! varying string
>
> n = vgets(unit,string) ! returns #chars (0 = error) in varying string
> input from unit

Yes. But what's the point? A supplementary set of procedures
is a supplementary set of procedures is a .... Why not just implement
the supplementary standard's procedures on ALLOCATABLE
strings? They're already standardized. We no longer need (or
necessarily even want) a varying-string data type. It's already
been suggested that it be removed. But the functionality is
already standardized. We need no new, or non-standard
variations.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

David Frank

2004-10-30, 3:56 am

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:ikHgd.804419$Gx4.307757@bgtnsc04-news.ops.worldnet.att.net...
> David Frank wrote:
> ...
>
> Yes. But what's the point? A supplementary set of procedures
> is a supplementary set of procedures is a .... Why not just implement
> the supplementary standard's procedures on ALLOCATABLE
> strings? They're already standardized. We no longer need (or
> necessarily even want) a varying-string data type. It's already
> been suggested that it be removed. But the functionality is
> already standardized. We need no new, or non-standard
> variations.
>

My original point was we dont need a supplemental varying string
package in F2003 as character(:),allocatable :: string is a varying
string.

My guess it will be supported in read statements by Intel's F2003 compiler
if users raise a hue and cry now. HUE!! CRY!!

If the standard says nothing about inputting to a allocatable string,
why would the Intel compiler be considered having a non-standard feature
in this regard?

Richard E Maine

2004-10-31, 3:56 am

"David Frank" <dave_frank@hotmail.com> writes:

> If the standard says nothing about inputting to a allocatable string,
> why would the Intel compiler be considered having a non-standard feature
> in this regard?

The f2003 standard does define what it means to input an allocatable
string that is allocated. The standard says the allocation does not
change. Changing it would be a violation of the standard.

If the string is unallocated, things are different. That's probably
illegal to do, in which case it would be a valid extension to do
something "useful". (I say "probably" because I think that is
correct, but there is at least a possibility that the standard says
that causes an error condition... which does have standard-defined
consequences. But I think this one is illegal instead of an error
condition.)

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Sponsored Links