Pascal Viandier wrote:
That basically all it does now. As I wrote, it doesn't have padding options yet, though space-padding and precision of reals can be given as in Write statements, e.g. FormatString ('%s', Pi : 10 : 5). (But we should add at least space- and zero padding facilities in the format string, indeed.)
What do you think about the idea of calling sprintf() from InternalFormatString after appropriate transformation of the format string and adaptation of the parameters?
I don't like it. I prefer to use C functions only where necessary (such as portable system interfaces or 3rd party libraries). String formatting is a high level task that can be implemented in Pascal.
One practical advantage is that we avoid getting system-dependent more than necessary. Some C libraries have some extra features in *printf, and some old ones may not even support printing long (e.g., 64 bit) integers -- this was the state of affairs some 8 years ago when I rewrote the `Write{,Ln,Str}' routines from *printf to self-made routines. Even if that might not apply today (and I'm not sure, since we don't want to support only bleeding-edge systems), other extensions do vary (and probably will in the future), and having an output that works on one system and not the other (and not because of range limitations, just different features in the C library) is not something I'd like to see.
After all, both have almost the same purpose with the advantage for sprintf for the formatting we would like to add to InternalFormatString.
I think the challenging part - for me - would be to pass the arguments to sprintf() since I do not understand yet how the parameters passing mechanism works.
It may be possible. But I'd rather spend this effort writing a better Pascal (Internal)FormatString.
You (Frank) wrote previously that one cannot make a Pascal function accepting a variable number of parameters. At my surprise FormatString is exactly that.
FormatString is not a regular Pascal function. It's a compiler built-in that's expanded to a sequence of "magic" RTS calls, one of the last of them being InternalFormatString. At this point, the variable arguments have already been pre-converted to strings and put in an array (`Strings^'), so the function only needs to deal with an array of variable size. (Admittedly, it currently doesn't use one of the standard ways (conformant array or schema) or BP open arrays but a formally-unbounded array, but we may change this, and it's unrelated to the "varargs" question.)
Frank