|
Boost : |
From: Samuel Krempp (krempp_at_[hidden])
Date: 2001-12-17 04:48:25
> I started with printf compatibility too but I found that it is not
> so important and it complicates the implementation. So I chose 1-1
> mapping between ostream flags and formatter flags.
I also hesitated between those 2 choices.
mapping exactly the stream flags makes a clean implementation,
but on the other hand many people don't want to use another syntax than
printf's, for the simple reason that thy know it by heart and have been
using it for decades.
Also, printf flags were probably designed after careful reflexion to
adress the most frequent needs. eg the '0' flag is indeed very useful.
What is your syntax for "<< setfill('0') << internal " ?
My idea is to design a superset of printf syntax, so that all stream
flags can be mapped into it, while fully supporting printf directives.
That's what I did (maybe it still lacks the ability to set a few stream
flags, in this case I would extend the syntax a bit more)
and it looks good to me.
(the extra flags, centered alignment and 'tabulations', might be
arguable. but that's a first try at finding new useful format-string
directives)
> I have factor 2-5 compared with ostingstream (it depends on compiler
> and STL library implementation). I didn't optimized my code yet.
same thing for me.
My guess is our 2 classes are doing the same thing, but chose different
roads at 2 steps :
1. syntax of format-string : printf-like or new one, exactly mapping
stream flags.
2. usability in the middle of output to ostreams. I wanted my class to
provide a stream operator<<, because the most frequent use of the class
will probably be to ouptut to an ostream, eg
cout << format(" %1 %2 ") % x % y << endl;
You chose to only provide a str() function. thus, we have to write :
cout << str( format(" %1 %2 ") << x << y ) << endl;
which is less pretty.
On the other hand, this way you have no need for an operator dedicated
to format, as I do.
this difference is rather superficial, and we both could switch to the
other system very easily, so it's rather a matter of taste.
BTW, is your code publicly available right now ? It would like to look
at it, and see the syntax you chose, and the details of implementation.
I could merge all the good things into the current format class, as mine
should not be very far from formal review, and provides natural advanced
features in a nice interface (the bind_arg mechanism to fix an argument,
set_flag to give/modify formatting option by stream manipulators out of
the format_string. see example/sample_advanced.cc ..)
I guess boost would not accept 2 similar classes with minor differences
in design,
so people should look at both alternatives and say which approach they
prefer for each of the differences, and then we would apply the changes
it imply to the class that is already the nearest to being ready for
formal review.
I think it is mine, but that's just my guess until I look at your code.
If people vote for your syntax rather than printf, adapting your parsing
and formatting code to my class will surely be easy.
For cout<< and operator% vs str() and operator<<, the changes
implied can be done in 1 minute..
-- Sam
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk