User talk:Zmi007: Difference between revisions
→Strings in Fortran
No edit summary |
|||
Line 23:
* Substring references are easy and straightforward, using standard (begin:end) notation.
* There is a complete set of character string intrinsic procedures ([ISO 2004], 13.5.3) extended(and simplified) also in next standards.
::Humm, I think it would be easier to have stated that although F95 did not supply varying-length strings such as you describe as a requirement, it did require that if an extension were to be supplied to do so, it would have to conform. I have seen such a package for F95, packed with turgid definitions just as I mentioned. Later versions such as F2003 (and the F2008 you mention) include these features, but I do not have access to such compilers and so had not perused their capabilities.
::I agree that marking the end by a zero as used in C-like systems is a plague, not only because I have wanted to use zero codes in the middle of a string for various purposes, but because it is improper. Also it is just asking for overflow errors, and it is idiotic not to know the length of a string without scanning it. Every time. However, I would not be happy in using these varying-length strings when changing the length (inserting, deleting or appending text) because of the overhead of allocation and deallocation of the working memory that is required. Perhaps I should just swallow it and smile. Certainly, the use in Pascal and pl/1 of strings with a fixed upper size but varying usage length (up to that size) meant no re-allocation and deallocation (and by contrast, I recall dynamic strings in Basic on the ibmpc, where every so often the system would hang while the string memory pool was defragmented or whatever, and all other activity ceased for minutes while say a paper tape or cassette tape reader overflowed its input buffer - happily, if the prog. was compiled and run, not interpreted, this problem didn't arise) but yes, it was annoying to have to think of a largest-possible-size specification. But not too large. I noticed in pl/1 (IBM mainframe) that if work areas declared as say <code>character(200) varying</code> were re-declared as <code>character(4000) varying</code> to reduce the chance of inadequacy, the execution on the same data would run noticeably slower. I wrote my own text editor in 2,400 lines of pl/i and had to choose a size for variable ALINE, which usually would not exceed eighty characters to a line, or 133 if looking at a printer file ... 200 will do. But this proved restrictive, as sometimes, odd files were to be inspected. It turns out that pl/i offers <code>character(n) varying controlled</code> for variables declared on entry to a procedure (or block) whereby a string variable of size ''n'' could be defined and used with lengths up to ''n'': there was one allocation but many usages without requiring deallocation and reallocation on length changes.
::If one is juggling a few strings to prepare a message or similar, then no worries, but needing to perform hundreds of millions of allocate/deallocate operations is something else. I wish there were a function FMT(x) for example, that would return a string holding the text of the value for ''x'', similar to the free-format output scheme, that could be used in statements such as <code>"Yes, we have "//FMT(N)//" bananas."</code> but F95 and CHARACTER variables require a fixed-size result such as " 7" rather than "7". I have even considered having the spurious spaces replaced by nulls (character code zero), but they might not be passed over by output devices and certain idiot systems would regard the string as terminating early.
::I have no objection to the various operators for messing with strings, though I have been startled by the implementation of some, at least as applied to CHARACTER variables as used in the F95 compiler I mess with. For instance, the latter-day library function LEN_TRIM(text) finds the last non-blank, but, the actual code first copies ''text'' to a work area then scans that work area!
| |||