Re: [boost] Re: formatting manipulator for UTF-8

From: Karl Nelson (kenelson_at_[hidden])
Date: 2000-08-21 13:56:53

David and all,

Did the i18n thread die?  What conclusions have we drawn?
Near as I could tell, David agreed that

- format("foo", T1,T2,T3) with templates
may run into some problems with selection of proper methods.
Although he didn't state whether this was a large enough
concern to use <<.  The main objections to << is that
it is 2 charactors over 1, and it doesn't allow clear markers
to end the format.

- printf format solves the separate problem of how to name 
changes to the stream in a non-sticky way.  Though it creates
the slight problem that our format will be fuzzy and thus 
not a perfect match.

- he needs a wide implementation, though a charT version is likely
overkill as 99.9% will just want the ostream and wostream varients.

Beyond David, Valentin, and myself there wasn't much comment on
whether this idea was acceptable for boost.

Now as for what I plan to do.   I don't have an implementation of 
STL with stringstream, wstrstream, or even wstream.  Nor do I 
expect that the users of Gtk-- will be installing their own
libraries which such C++ features.  I can however write a configure
script that identifies features in the STL like stringstream and
use them where applicable.  (the difference between using stringstream
and strstream is all of about 3 lines for my code. )

Assuming that is acceptable we are back to the more generic questions
what should this thing look like.

After reading Valentin Bonnard's code and others from
the archives I do see some areas for improvement in my code.  
I could easily allow format to be base class (rather than
a stub as it currently is) which cleans up the code, and
just add a stringformat type using similar code.

  string s=stringformat("%.4f") << 1.0;
  cout << format("%.4f") << 1.0;
  format(cout,"%.4f") << 1.0;

  cout << format("The result is %^25s") << 
     ( stringformat("%.3f != %.3") << i1 << i2 );

  (where %^25s, means a 25 wide centered string)

This would both simplify the code and make life much easier on
the programmer.  It would also then be largely equiv to the
boost current proposal in terms of capablity though perhaps with
some lose of clarity.

--Karl