what about a new printf?
io_x
in the best of all what i know i could write only one printf
that follow a subset of the laws that printf should follow
(the trick is choose the laws that are ok and
easier to implement :) )
so in the search for to write "the C printf" i found
a "printf" like function that instead that print the
argument print what the arg point. And i think that what
follow is better of what follow from the original "printf".
What do you think on that?
-----------------------------
what about a printf like function that instead of print the value
print what that value point; something like:
#define u32 unsigned
u32 a=2;
u32f32 v; // fixed point number 32.32 bits (it is a struct or a class?)
u1024 h;
printf(" %u32 ", &a); // print "2"
printf(" %u8 ", &a); // print first 8 bits from what point &a
printf(" %u1024", &a); // print 1024 bits like one number that start from &a
printf(" %s \n", "this is a string"); // print the usual "this is the string"
printf(" %u32f32 ", &v); // "1234.123456"
how is it possible to add to printf new user define type for print?
fnum
h=2222222222222222222222222222222222222222222.7777777777777777777777777777;
// user defined class memorypossible.fixedsize
printf("%fnum \n", &h);
//2222222222222222222222222222222222222222222.7777777777777777777777777777
Fred
In this new design, how would you implement the equivalent of this:
int foo();
printf( "%d\n", foo() );
--
Fred K
Gordon Burditt
more than adding an (unnecessary) level of indirection.
I recommend that a new version of printf() be named something other
than printf(), especially since the proposed version is very
incompatible with the standard version. Standard C does not define
a way to add new conversions to printf() - and the examples shown
(like %u32) already have a meaning in Standard C printf().
I think it's a poor idea to make it much easier to have format/argument
type mismatches by avoiding the default argument promotions.
Seebs
I once wrote up a design for (and partially implemented) a printf which
allowed additional conversions using something like %<. So:
extprintf("%2.2<", my_formatter, (void *)&arg);
would call my_formatter with flags = 0, width = 2, precision = 2, and
pointer-to-parameter of arg.
I actually think it'd make a nice extension, but it's probably too high
impact for not enough benefit.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
io_x
"Fred" <fred.l.kl...@boeing.com> ha scritto nel messaggio
news:bd9e3105-a59f-4bc4...@h14g2000pri.googlegroups.com...
int foo();
--
Fred K
#i would write "printf( "%d\n", foo() );"
#or i would write
#int k;
#printf( "%i32", (i32*)( k=foo(), &k));
Nick
> On 2009-12-17, Gordon Burditt <gordon...@burditt.org> wrote:
>> What does "print what the arg point" mean? It seems to be doing
>> more than adding an (unnecessary) level of indirection.
>>
>> I recommend that a new version of printf() be named something other
>> than printf(), especially since the proposed version is very
>> incompatible with the standard version. Standard C does not define
>> a way to add new conversions to printf() - and the examples shown
>> (like %u32) already have a meaning in Standard C printf().
>>
>> I think it's a poor idea to make it much easier to have format/argument
>> type mismatches by avoiding the default argument promotions.
>
> I once wrote up a design for (and partially implemented) a printf which
> allowed additional conversions using something like %<. So:
> extprintf("%2.2<", my_formatter, (void *)&arg);
> would call my_formatter with flags = 0, width = 2, precision = 2, and
> pointer-to-parameter of arg.
>
> I actually think it'd make a nice extension, but it's probably too high
> impact for not enough benefit.
I did a bit of thinking around something similar, but what I wanted to
do was to find a way to "register" a new format. I never got beyond
thinking about it, as I stalled on the lack of an easy way to call the
register function by including a header file (it would be really nice if
the header file for a library to handle, say, a string library added the
new printing routine to [...]printf).
Other worries were the namespace problem (although that's C as a whole
really), and the messyness of whether I could, say, get it to work on
simple types (a binary format for integers would be a good extension),
structures and pointers of all types.
--
Online waterways route planner: http://canalplan.org.uk
development version: http://canalplan.eu
io_x
"Gordon Burditt" <gordon...@burditt.org> ha scritto nel messaggio
news:v-SdnRHD3dNPJrTW...@posted.internetamerica...
> What does "print what the arg point" mean? It seems to be doing
> more than adding an (unnecessary) level of indirection.
yes,
but if you have one class, or one struct of some KBs
the way of print it is pass one pointer to the print function
and not copy all the KBs on the stack for print
(if pass the struct like argument of the function)
> I recommend that a new version of printf() be named something other
> than printf(), especially since the proposed version is very
> incompatible with the standard version. Standard C does not define
> a way to add new conversions to printf() - and the examples shown
> (like %u32) already have a meaning in Standard C printf().
yes this is true "%au32" whould be better?
Phil Carmody
> On 2009-12-17, Gordon Burditt <gordon...@burditt.org> wrote:
>> What does "print what the arg point" mean? It seems to be doing
>> more than adding an (unnecessary) level of indirection.
>>
>> I recommend that a new version of printf() be named something other
>> than printf(), especially since the proposed version is very
>> incompatible with the standard version. Standard C does not define
>> a way to add new conversions to printf() - and the examples shown
>> (like %u32) already have a meaning in Standard C printf().
>>
>> I think it's a poor idea to make it much easier to have format/argument
>> type mismatches by avoiding the default argument promotions.
>
> I once wrote up a design for (and partially implemented) a printf which
> allowed additional conversions using something like %<. So:
> extprintf("%2.2<", my_formatter, (void *)&arg);
> would call my_formatter with flags = 0, width = 2, precision = 2, and
> pointer-to-parameter of arg.
>
> I actually think it'd make a nice extension, but it's probably too high
> impact for not enough benefit.
It's lovely! In some ways the hard-coding of the concepts of
just 'width and precision' might be too restrictive, having
myformatter called with a pointer to its relevant subsection
of the format string might be more general. (But of course,
you could just have a different formatter for each variation.)
Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
Bruce Cook
>
> I did a bit of thinking around something similar, but what I wanted to
> do was to find a way to "register" a new format. I never got beyond
> thinking about it, as I stalled on the lack of an easy way to call the
> register function by including a header file (it would be really nice if
> the header file for a library to handle, say, a string library added the
> new printing routine to [...]printf).
>
> Other worries were the namespace problem (although that's C as a whole
> really), and the messyness of whether I could, say, get it to work on
> simple types (a binary format for integers would be a good extension),
> structures and pointers of all types.
On a project I was working on in the early 80s & early 90s we had our own
formatter that allowed dynamic registration of new types. Dynamic
registration allowed you to register new type as you bought in dynamic
libraries which we found extremely useful.
so useful in fact that no one on the project used printf() ; mprintf() was
the favored function.
I developed it initially when we started working with segmented memory
systems and needed to be able to print pointers in a sane format which
nothing in printf() at the time could achieve.
The peak achievement was when we created a format construct that took a
pointer to an object, fed it back through our object system engine and
printed the object out in a useful format (with formatting hints).
bloody useful.
Bruce
Moi
> Seebs <usenet...@seebs.net> writes:
>
>> On 2009-12-17, Gordon Burditt <gordon...@burditt.org> wrote:
>>> What does "print what the arg point" mean? It seems to be doing more
> I did a bit of thinking around something similar, but what I wanted to
> do was to find a way to "register" a new format. I never got beyond
> thinking about it, as I stalled on the lack of an easy way to call the
> register function by including a header file (it would be really nice if
> the header file for a library to handle, say, a string library added the
> new printing routine to [...]printf).
>
> Other worries were the namespace problem (although that's C as a whole
> really), and the messyness of whether I could, say, get it to work on
> simple types (a binary format for integers would be a good extension),
> structures and pointers of all types.
Gnugo supplies an extension to the formatting by means of %m :
format a move. It expects an object of type "move_t" or such as an
argument and prints it as "D4", or such.
IIRC GNU's libc has a way to supply such a hook to the
printf() family to add such an add-on.
IMHO, the problem with printf() et.al is that the format string
describes *both* the argument type and the way it should be displayed.
This can be disturbing for newcomers. (eg %c expects an int (but type
promotion takes care), %x expects an unsigned int).
AvK