Date: Wed, 08 Sep 2010 13:30:17 -0700 From: Bakul Shah <bakul@bitblocks.com> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: FreeBSD Arch <freebsd-arch@FreeBSD.org> Subject: Re: printf Re: Extending sbufs with a drain Message-ID: <20100908203018.253A95B38@mail.bitblocks.com> In-Reply-To: Your message of "Wed, 08 Sep 2010 19:18:33 -0000." <67864.1283973513@critter.freebsd.dk> References: <67864.1283973513@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 08 Sep 2010 19:18:33 -0000 "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote: > In message <20100908185848.96D5D5B81@mail.bitblocks.com>, Bakul Shah writes: > >On Wed, 08 Sep 2010 17:38:42 -0000 "Poul-Henning Kamp" <phk@phk.freebsd.dk> > wrote: > > >If it was just printf/scanf family, one can perhaps hack > >gcc/clang to generate a default fmt string for each type, > >available with a `formatof' compile time function. Then one > >can do, for example, > > > > struct {int x, y;} z; > > printf("z=" formatof(z) "\n", z); > > printf("z->" formatof(&z) "\n", &z); > > > >But even for such a simple case most of us would disagree on > >just what formatof(z) should be. > > Indeed, not to mention that we still want to retain the padding/ > width specifcation so things can be aligned nicely over multiple > lines. > > There are conflicting issues here, but they all boil down > to the look of the source-code. > > It is instructive to notice that the C++ "<<" stuff never really > hit the mark except as a convenient debugging facility: Most people > still fall back to *printf() for the actual formatting. > > If you survey other programming languages, the best they do is > provide a default string representation, but seldom with any > bells and whistles. See Common Lisp's format function. Even its bells and whistles have bells and whistles -- it may even be turing complete:-) http://www.gigamonkeys.com/book/a-few-format-recipes.html http://www.lispworks.com/documentation/HyperSpec/Body/22_c.htm But then most things are easier in Lisp/Scheme & a wrong format won't make your program crash. > And at least my attempts at a sensible advanced printf syntax > has been anything but, making the lines sufficiently unreadable > that I couldn't be bothered. Exactly. But some of us can't help attempting to do so! > I think the strength of the printf model is that the format spec > is very compact, as soon as you embellish it, the model falls apart, > and you suddenly need really strong compile-time checks to not make > silly mistakes. (in the absense of typesafe varargs). > > If we can get over the disappointment of not being able to write > the entire formatting statement in a single transparant source line, > sbufs are an eminently workable solution, in that you can define > your own formatting functions, like: > sbuf_sockaddr(struct sbuf *, struct sockaddr *) > and call that as much as you want, without getting bogged down in > error checking. > > But: > sbuf_cat(sb, "Client address: "); > sbuf_sockaddr(sb, &sa); > sbuf_cat(sb, "\n"); > > Does not compete with: > > printf("Client address: %{DWIM}\n", &sa); > > In any other way than by being feasible and available. > > >This is why I like the plan9 idea of allowing users to > >associate their own function with a given format char. > >[you don't get type safety but you get flexibility] > > We have that, see /usr/include/printf.h for userland. > > Problem is that the benefit from using it is quickly lost to not > having any printf format-checking from the compiler anywhere. How about somehow combining formatof with this? Hmm.... how about a new specifier that means the next argument is formatted with a function? For example, if we use & as a fmt function specifier, printf("Client address: %16&p\n", sa_fmt, &sa); or more generally printf("Client address: %16&" fmtof(&p) "\n", sa_fmt, &sa); Now fmtof is used for typechecking and advancing over the given argument but it is upto sa_fmt to convert sa to a string. Or how about visually embedding the function in the string? printf("Client address: %16" @sa_fmt "\n", &sa); The compiler would map this to the previous form. [Throwing this out just in case it triggers some new ideas]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100908203018.253A95B38>