(j3.2006) internal writes to deferred length strings?

[Bill Long]

> On Jul 28, 2017, at 8:28 AM, Clune, Thomas L. (GSFC-6101) <thomas.l.clune at nasa.gov> wrote:
> 
> I?m a big fan of deferred length strings and now use them heavily in my code.    Having said that, there are few use cases where the existing functionality is a bit frustrating.   The most common one is the following:
> 
> 
> character(len=:), allocatable :: string
> character(len=10000) :: buffer ! big enough?
> integer :: list(3)
> 
> ...
> 
> write(buffer,fmt)  list
> string = trim(buffer)
> 
> 
> It is annoying to have the extra buffer variable and esp. annoying to be certain that it is ?big enough? for all use cases.    It would be terribly convenient though if the WRITE statement could directly allocate a deferred length string to the needed size:
> 
> write(string, fmt) list ! allocates string and fills

Not that easy to do in practice. You have to work through the format to compute the length of string before allocating it. So the allocation would have to occur inside the I/O library.  The library is probably currently expecting only an address and length for the output buffer   Potentially several worms in that can. 

> 
> 
> 
> Of course, having WRITE() automatically allocate deferred length strings would beg the question of what to do if the string were already allocated.   E.g., some might want the string shortened as we do for array assignments and differently sized arrays.   For myself, the reasonable compromise would be to leave the case with allocated strings unchanged, and only modify the result when using an unallocated deferred length string.

I?ll predict that someone will want the string reallocated if it needs to be longer, avoiding an I/O error.   We already naturally handle the case where the string is longer than necessary to hold the output. So, I could see leaving that unchanged. 

> 
> Other objections could also be:  (1) The vendor might need to allocate additional scratch space to safely determine the necessary string length.  or (2) performance loss due to the check on allocation status.
> 

Automatic reallocation is already an anti-performance feature. WRITE statements, in general, are not stars of the performance stage either.  The first objection is more relevant.  The likely implementation would be to use an internal buffer for the WRITE operation and then separately implement an assignment to the string variable using the existing rules for a variable that is allocatable character with deferred length.  Basically your first example, except that the I/O library could incrementally extend the effective buffer by allocating another chunk of memory if it filled the existing buffer space before competing the WRITE. Then logically concatenate the chunks to form the RHS for the assignment to string. 


> Any thoughts/opinions?
> 

A fair amount of work for implementors. We need to judge whether this is where we want developer time spent at the expense of some other feature. 

Cheers,
Bill


> - Tom
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425