🚀 go-pugleaf

Peter Seebach (seebs@solutions.solon.com) wrote:
: Consider the function
: fmtcheck(char c, int (*fmt)(some args));

: This would be like atexit(), and would indicate that the given char
: should be processed by the function fmt(), which
: would take as args the character triggerng it and any flags.
: fmt would return -1 and set errno for errors, or return the
: length of the string copied into a buffer provided it, and
                                                    ^
                                                'by' or 'to' ?
: probably also a maximum allowed length.

The 509 character limit for a conversion?

<snip>
: Can anyone see any big wins or losses?   I think this would be an
: amazingly neat addition to C9X - it would allow us to get the features of
: cout, without the mistakes.  (IMHO.)

I would prefer to see one of the args being a function to call for each
character generated rather than passing a buffer. This would make it possible
to remove the size limit in some future version of the standard.

If you are doing this I would also add a general printing mechanism where
by on can one print formated to anything by providing a suitable put function. 
This can either be done with a new printf type function:
        int gprintf( int *put( void *context, char toprint ), char const fmt, ... )
        ['g' for general]    ['context' for any user defined context structure]
or even more 'cout' like to generalize the FILE structure and provide a 
new open function which gives a FILE* that can be used to fprintf to a
function:
        FILE *gopen( int *put( void *context, char toprint ) );
or 
        FILE *gopen( int *put( void *context, char const *toprint, size_t len ) );
The first of these would print each character separately. The second would
do a buffer at a time as determined by the setbuf() setting.
One probably needs to provide either a put and get function or a r/w mode or
something.

I prefer the 'gopen' solution though some would prefer 'gprintf'as being 
slightly simpler to use, though less flexible. It may be useful to have both.

--
Stephen Baynes                              baynes@mulsoc2.serigate.philips.nl
Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom