Re: [boost] Alternate Format Mechanism

From: Karl Nelson (kenelson_at_[hidden])
Date: 2002-02-11 16:11:08

First suggestion then.

Rename it "reorder()".  One more letter, but it gets
out of the "what do we want in formatting" discussion.
Limited scope things get going faster than others.

Format is already pretty tied up with 2 discussions and 
the boost submission which using format for both reorder
and printf-format was generally regarded as a bad idea. 

Second suggestion.  

Don't use "%1" this is too easily confused with other 
formats ie.  Is this a printf format or yours?
   I see %1s.

Use [1] (boost suggestion) or {1} (.NET).  Also this avoids
the ending tag problem.

> > That is a bit better, but it completely excludes
> > everything but reordering.  Catching things at 
> the
> > streambuf layer means all of the manipulators 
> have
> > been applied and the thing is now in string 
> form.
> > So although it can use arguments multiple times
> > it certainly won't be able to use them with 2 
> different
> > formats.
> 
> Of course not.  I didn't see at first that this 
> was the purpose of these statements.

I believe that .NET and others which support 
multiple uses are different translation on both.

[...] 
> > > (iii) it behaves well with user-defined types 
> > > (like format2); 
> > 
> > I believe all of them currently work with user 
> types
> > because they all proxy to ostream <<
> 
> Sorry, this comparison is with another interface 
> I considered and rejected.  But your example from 
> format3 used type specifiers; I assume these are 
> optional? 

Yes.  "%s" is really unspecifed type. 

 
> > > (iv) it deals with repeated arguments like "%
> 2 %
> > > 2" at no extra cost beyond the output 
> operation; 
> > > and
> > 
> > Assuming they must be formatted identically.
> > 
> > 
> > > (v) it behaves sensibly when nested (this is 
> more 
> > > pleasant with the extension I describe below).
> > 
> > 
> > Disadvantages:
> >   - not possible to place any manipulator in
> >     info in format string.
> 
> I guess it replaces the bare format, and none of 
> pformat; in this, it doesn't duplicate existing 
> functionality.  I'm not convinced it is 
> beneficial for this information to be dealt with 
> by the translators -- it seems likely to cause 
> errors which the application can't deal with, as 
> is being argued in other threads about exception-
> throwing.

Exceptions (where and when) in formatted text
seems like a hard problem which no one has a 
satifactory answer for.

> 
> >   - doesn't really handle use with strings, but
> >      you can do that through
> > 
> >      ostringstream os;
> >      os << format<char>("%2 %1")<< a >> b 
> <<endf;
> >      string s=os.str();
> > 
> >    (This seems error prone in that don't streams
> >     expect their buffer to stay the type they 
> created?)
> 
> All I can say to that is: If they do, they are 
> severely broken -- basic_iostream doesn't have 
> virtual functions and hiding virtual functions is 
> flawed; and relying on the return type of rdbuf() 
> being something other than the declared return 
> type requires a (dynamic) cast, whose error 
> condition should be checked.  If this isn't the 
> way in which rdbuf() is supposed to be used, why 
> isn't it protected?

Okay I am wrong here.  

Checking g++, they keep the stringstreambuf in
the class and thus don't access the copy kept by
ostream.  Thus you can make it work, but you are
going to have to document that things like 
below are an error

   ostringstream os;
   os << format<char>("%1 %2")
   os << i;
   string s=os.str();

Here the string stream will not have gotten the charactors
yet as it is still trapped in your proxy buffer.

Carefully document interactions here and then submit.

> > > manipulators and other output operators 
> return 
> > > ostreams.
> > > 
> > > This gives me a syntax like:
> > > 
> > > complex<double> a=4,b=5,c=11,d=67;
> > > cout<< format<char>("%1 %3 %2 %4 ");
> > > cout<< a >> b >> c >> d >> "foo!" << endl;
> > 
> > This seems dangerous if iostreams are used.
> 
> Yes.  I wish there was another operator with the 
> same precedence.  As I say, the only good thing 
> is that the << or >> or manipulator nearest the 
> stream object controls the input/output semantics.
> Thus,
> 
> fstream file("somefile");
> file<<format<char>("%1 %3 %2 %4 ");
> file<< 5 >> 6 >> 7 >> 8 >> endl;
> 
> is all output, not an erroroneous attempt to 
> input into literals.  Of course, one could still 
> easily do
> 
> file<<format<char>("%1 %2")<<foo;
> file>>bar>>baz;
> 
> and be suprised when bar and baz don't get output.
> Both
> 
> file<<format<char>("%1 %2")<<foo;
> file>>hex<<bar>>endl;
> 
> file<<format<char>("%1 %2")<<foo;
> file>>bar>>"\n";
> 
> and variations thereon naturally cause errors.  
> The only way in which it gives maximal surprise 
> is when you have an 
> iostream>>var1>>var2>>...>>varn; statement with 
> no literals and no attempts to do un"tabbed" 
> output.

This is a fair bit of a downer.  But lets see if 
others feel is a problem.

--Karl