Re: Concatenate integer to string

Richard E Maine wrote:
Joe Krahn <krahn@xxxxxxxxxxxxx> wrote:


The one huge simplification would be allowing a return type of character(len=*) instead of requiring a separate length function, especially in the case of float-to-string.


Ah. Do you actually mean a return type of character(len=*) as per the
standard, or perhaps do you mean a "sensible" variable length return.
Functions returning character(len=*) are obsolescent and with good
reason. They do *NOT* do anything close to what you might think or hope.
What they do is darned quirky. Basically, just like with a len=*
argument, the length is specified by the invoking routine. Read that
again to make sure, because yes, I meant the invoking routine. The
length is *NOT* determined by anything inside of the function.

Worse, the length is specified by declarations in the invoking
procedure, not by anything in the invocation. Thus, this has the
peculiar property that if you invoke the function multiple times from
the same procedure, all the returned lengths will be the same.

My observation is that 90+% of the people why try to use
character(len=*) function results don't actually understand how they
work and are trying to do something that this won't do. Most people who
understand what this does don't use it. There are exceptions, including
among people who have posted here, but darned few of them.


Somebody mentioned true variable-length character strings being added to
Fortran, which I hope are true (len=*) strings, and not just the built-in version of ISO_VARYING_STRING. Can someone comment on this? Is
it in F2003 or F2008? Fixed string-length is the one major nuisance in
having useful string functions in Fortran.


F2003 adds allocatable-length strings. In my opinion, they act pretty
much the way you would want a variable-length string to act. They are
not a separate type, like the ISO_VARYING_STRING stuff. Consequently, I
think that they integrate with the rest of the language far better than
the ISO_VARYING_STRING stuff. You don't need to go add special cases all
over the place to allow use of them. Since a character with allocatable
length is the same type as any other character, anything that accepts
characters already accepts allocatable ones with no extra work. If you
want a subroutine to be able to do the allocation, then it needs to know
about its argument being allocatable, but of you have somewhere that
just wants to use the string without changing its length, it doesn't
even need to know about its being allocatable.

OK, if I understand correctly from the N1601 document, these strings are character(len=:), meaning deferred size instead of (len=*) assumed size. It seems that the deferred length has a special proparty, different from a deferred array size, in that the standard assignment operator will [re]allocate the length.

Now I'm confident that Fortran progammers don't need stuff like Python, just better text utility libraries.


In particular, yes, functions can have allocatable-length character
results, and they work in a way that I consider more or less intuitive
(which is to say, nothing even close to the non-intiutive way that
current character(len=*) functions work).

There is one thing about some of the new allocatable stuff that confuses
some people, though I personally find it sensible. Mostly it hits those
folk who are inclined to write x(:) instead of just x to indicate an
array x. The form x(:) indicates an array slice or a substring,
depending on what x is (same principles involved for both cases).
....
I was not aware that some people used a '(:)' suffix for arrays. This is where some name conventions are useful. For example, you can have an 's' suffix for arrays, which works well if your names are words, like 'coordinates'. A more verbose computer-science approach would be to have a prefix, like 'm_' or 'mat_', or even include the rank: m2_ m3_. A more mathematical style would be to use upper case for arrays and lower case for scalars (but not as useful in a case-insensitive language).

With Fortran being mathematically oriented, I wonder if people have suggested expanding the character set for variable names. It might be an interesting idea to have greek letters, etc., in the code. To me, it seems like a lot of typing hassle, but many people whose native language uses non-ASCII characters might think it is not so hard.
.

Relevant Pages

  • Re: (*) and List Directed I/O
    ... character n of a character string could be accessed as b, ... of strings. ... || reference unless foo is declared as an array. ... || is a function reference. ...
    (comp.lang.fortran)
  • Re: Array range assignments and characters
    ... This follows the rules of assigning a scalar to an array. ... character t3*8 ... as a single character string/array has been used to contain 2 strings ... directly like Fortran character strings. ...
    (comp.lang.fortran)
  • Re: (*) and List Directed I/O
    ... >>> character n of a character string could be accessed as b, ... The ambiguity is that stringis assumed to ... > reference unless foo is declared as an array. ... decided to consider strings to be scalars and the presence ...
    (comp.lang.fortran)
  • Re: Fortran/C string interop?
    ... C strings than Fortran character strings are. ... A Fortran array of type character with a kind type parameter equal to C CHAR is interoperable with a C string. ...
    (comp.lang.fortran)
  • Re: K&R2 Secition 5.9 - major blunders
    ... Each element of b doesn't point to a 20 element array of int. ... This mistake is crucial because ... my explanation is really the qualities of something else: ... > The use of the array of pointers is to store the strings. ...
    (comp.lang.c)