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

[Clune, Thomas L. GSFC-6101]

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


This also arises when using environment variables and command line arguments

         call get_command_argument(i_arg, length=length)
         allocate(character(len=length) :: argument)
         call get_command_argument(i_arg, value=argument)


This case is not really a problem because it is a simple matter of wrapping this sequence in a procedure.    But the former case cannot generally be wrapped because of varying io-list requirements.   (Actually, with great pain, I?ve managed to do something a bit generic using a vector container of CLASS(*) entities and heavy use of preprocessor to keep the verbosity at a tolerable level.   But even that was a bit custom and not the thing you?d want to sprinkle in the file-name processing section in the I/O component of your model.

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.

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.

Any thoughts/opinions?

- Tom

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20170728/ab66e3c8/attachment-0001.html