From: Karl Nelson (kenelson_at_[hidden])
Date: 2002-02-19 12:05:13
> On 2/12/02 11:07 AM, "Karl Nelson" <kenelson_at_[hidden]> wrote:
> > Should we just define a subset of printf which is common between
> > iostream and support that or graft a whole lot which is isn't?
> > Ie. truncation of strings is in printf but not iostream,
> > padding with 0 and show base are in iostream but do not interact
> > like printf. (00000x1 rather than 0x00001)
> > Is it acceptable to just make close to printf with well
> > documented differences or is strong compatiblity the best option?
> If it was up to me, I would opt for strong compatibility. I don't think of
> this as an extension to ostream, but rather a suitable implementation of
> printf-style formatting to use in C++. Working well with ostream and string
> seems like a requirement. Using ostream as implementation machinery does
Okay, if strong compatiblity is best then that should be the direction
we should go. I still don't know which code base is the best
mechanism to achieve that. I think though that I can make the
printf compatiblity even stronger by trying to factor it with
a to_string form. It might give us a smaller code base with the
ablity to do
cout << format("%c",65);
and get "A".
string to_string(65, "%c")
which should return "A".
I am still not sure how you can pull that off and still support
group or manipulators. It would seem to interfer.
> Using ostream to efficiently implement this with a minimum amount of code
> was your idea, and I think it's a pretty good one. But it might get in the
> way of doing a good job at printf compatibility.
Yeah, but it is still worth a try to use as much mechanics as possible.
Small code bases to pull of tasks like this would seem to be
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk