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

From: Karl Nelson (kenelson_at_[hidden])
Date: 2000-08-21 16:51:57

> on 8/21/00 11:56 AM, Karl Nelson at kenelson_at_[hidden] wrote:
> 
> > Beyond David, Valentin, and myself there wasn't much comment on
> > whether this idea was acceptable for boost.
> 
> I'd love to have something like this in boost. Two things like this in boost
> would be bad though.

Agreed.  I am not particularly set on my design, but felt mine was
most likely to work on the current broad range of compilers.  However,
seeing as my Gtk-- users seem to think the design is decent I will 
resubmit it when it is better formed.

 
> > 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 know of at least two users of Gtk-- (me and one other) who plan to use
> libsigc++ on Macintosh with CodeWarrior Pro 6 (which has stringstream,
> wstrstream, and wstream); but it's true that we won't be using Gtk-- there.

Wow cool.  Be sure to tell me how it goes on that system.

> The only platform I program on regularly that lacks stringstream is the
> current Unix/gcc world; that's the anomalous one in my opinion.

Very true.  I could provide a "strstream to stringstring" wrapper
though that will suffer from rather poor performance in some areas.  
It would at least reduce the number of problems in making the
code work between gcc and rest of world.

> > 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. )
> 
> Ironically this does no good for Macintosh since configure scripts aren't
> used there. One thing I like about the boost library is that there are no
> dependencies (or few at least) on things like configure and automake.

How does the libsigc++ conf system seem to you?  There I placed a
configure script but also a default config header which recognizes
loads of common compilers.  The result is that in Unix world were
compilers have lots of variations the configure takes over but
in the others you just get the right settings out of the box.

 
> > 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)
> 
> I like the idea here, but not the name. Is there a compelling reason to cram
> the words string and format together without punctuation?

trying to follow the hideously bad STL conventions.  Of course,
I have never managed to follow what exactly is the STL conventions.
Sometimes they hash the names, other times just squish together
two words in strange combinations.

I am happy with anything from
  sformat, strformat, str_format, stringformat, string_format,
  format_stream, formstream, strformstream,  ...

I other words name a term you like and most likely it is fine by me.  :-)
  
> Sadly I have not had time to discuss the two current proposals enough to
> evaluate them. I do like Karl's approach of matching printf format strings
> closely instead of inventing a new format string language.

That is okay.  Hopefully after some more refinements mine will be
better to discuss,

Thanks

--Karl