CBFalconer wrote:
No, I mean that C programmers have no built-in way of dealing with streams other than with scanf, which is normally a horror for error recovery. So they prefer to read complete strings (normally requiring a presized buffer [1]) and do conversions from there.
Actually, I prefer to do the same in Pascal most of the time, because my parsing needs are more complex than a simple field-by-field numeric input. (Actually, most of the time, at least some of my input fields, usually the first one(s), are strings. And since strings can contain spaces, and reading strings doesn't (and shouldn't) terminate at a space, I'll have to parse things myself anyway). The distinction between generic I/O errors (in the `Read (MyFile, StringVar)' calls) and numeric parsing errors (which I usually get via `Val') usually comes in nicely because I often handle them differently. (The former would be more like an internal/fatal error (after proper checks before `Reset' and for `EOF'), while the latter is usually a user error.)
So my question is really not whether to convert between strings and numbers, but only how to (most elegantly). Numbers to strings are easy to do with standard functions (such as `Integer2String') because the integer is a value parameter and thus quite flexible, and there are no error conditions (since the result type can be chosen big enough to hold any possible value). Strings to numbers is a little more tricky, since there are error conditions, so the result and the error cannot both be the result.
The conversion routines for this normally pre-exist to implement write(textfile, ...). The only thing necessary is to extend that mechanism to strings. I would consider a cleaner method to be providing a way to attach a file to an internal string. However, as you say, the need to perform reset/rewrite on such a 'stringfile' might be exorbitant. Thus a family of sread and swrite(string, index, ....) might be easier. Again, they would draw on the same underlying routines. The usual colon syntax for field size etc. would be useful.
That's all already there (`WriteStr' (EP), `Str' (BP)).
AFAICS read and write are the only routines that are 'overloaded' in Pascal,
Not really. `Reset' etc. are as well (different file types), many file routines (optional `Input'/`Output'), `Abs' (Integer and Real) plus several more mathematical functions (especially if you take complex numbers in EP), `New' (varying number of arguments even!), `Dispose', `Pack', `Unpack', `Succ', `Pred', `Ord' and probably some more ...
It may be useful to include a var parameter for the current string index, by which time the function looks much like your proposal above,
Not really. My intention (with the Boolean return value) is, e.g., to be able to use the function in conditionals, and not having to declare an extra variable, when (as most of the time) I just want to convert a string to a number and reject anything invalid. (Corrective action can be nice sometimes, but since it's necessarily heuristic, I often find it better to just reject invalid input and let the user correct things.)
I include 'let the user' in corrective actions.
My "let the user" usually means aborting (the program if batch, or the routine) and let them try again.
I second your attitude to varargs. However I have usually found that unsigned operations are relatively rare, given proper subrange typing.
I think so too (especially on 32+ bit machines -- on 16 bit machines the additional range between 32768 and 65535 was sometimes more valuable, whereas the difference between 2G and 4G is less often important).
Depending on how the typing actually works, the definition "TYPE unsigned = integer;" should avoid misuse.
Unfortunately not, since such types are entirely compatible. E.g., if `u' is of this type, it wouldn't prevent `u + u', `Read (u)', `Write (u)', `MyIntegerFunc (u)', which would be all be wrong when applied to an such an "unsigned" value outside of the `Integer' range.
Making unsigned operations stand out avoids many silly errors. To me, the compiler magic to which you object is using the same operators as for integers.
I did not object to compiler magic (I said C does). In fact, I endorse it (in this and several other cases).
Frank