Re: [boost] Preminary submission: format3

From: Karl Nelson (kenelson_at_[hidden])
Date: 2002-01-31 01:33:28

> On Thu, 2002-01-31 at 00:39, Karl Nelson wrote:
> > Because most people have no liked use of an operator like << and %,
> > I have switched to a printf style for up to 9 arguments.  Ie.
> > 
> >   cout << format("%s, %s %d, %d:%.2d\n", weekday, month, day, hour, min);
> 
> This is also my favorite.

I still perfer << even with the lumps, but I will take comma list
as a close second. 

> except, of course, the 9-arguments limitation makes the C++ equivalent
> to C's printf look miserable.
> (even 100-arguments)

Yeah, that is why I went with up to 9 with the option of
more using extra arguments.

  cout << format(str)(i)(j);
==
  cout << format(str, i, j);

I think though that more than 9 needing a different style isn't
that big of deal as very few times I have needed more than 9.

> if not for that, I would also have made operator% a member function, say
> 'with(..)', and provide dozens of N-ary constructors, calling with(..)
> on each argument.

> and in fact, I did propose on the list to define both a {1,..N}-ary
> function call and an operator mechanism for using format.
> 
> > And of course arbitrary numbers
> > 
> >   cout << format("%s, %s %d, %d:%.2d\n")(weekday)(month)(day)(hour)(min);
> > 
> > It supports reordering... (for German translation say)
> > 
> >   cout << format( "%1$s, %3$d. %2$s, %4$d:%5$.2d\n",
> >       weekday, month, day, hour, min);
> 
> This is mostly the same as in the reviewed format library.

Yep.  However, considering the level of debate I don't doubt that
other alternatives will get submitted.  I have never had a problem
with using "printf" format as the basis, so long as it isn't
deviated from too much.   

> The main essential divergence between it and your ofrstream, was the use
> of operator<< , because of whose precedence your ofrstream was using
> proxy classes; and this is no longer the case.

Right.  I reworked the printf parser to use stringstream rather
than strings directly.  I needed a stream for the widen/narrow and 
it cut out the atoi or hand conversion of numbers.

 
> the choice of the syntax is one of the issues raised during the review,
> and still debated.
> the general advice is to accept printf format-strings by default, and
> maybe provide some other syntax, and actually the final submission I'm
> preparing is using printf by default.
> 
> your 'group' function is a bit more satisfying than the current 'manip'
> function.
> Indeed, providing it with {2, .. 10}-ary variants would be the most
> satisfying method to pass manipulators along arguments seen until now.
> On this aspect, you face the same problem, that prevents the compilation
> of :
> cout << format("funky %s\n", io::group(hex,10) );
> That is because manipulators can not all be passed by const reference. 
> I had solved that in g++3.0 with T& / T const& overloads, and in MSVC 
> by passing manipulators by value. (this was discussed in the list)
> If we extend it to support up to 9 manipulators at a time, we'd use
> by-value for both g++ and MSVC. (else it makes 1000 different functions
> template)

Unfortunately making group for 10 would take 2^10 templates because
you would need to have group(T&,const T&,...) for 2^10 combinations
of const T&/T&.  It would be better just to switch to the 
iomanip implementation I submitted earlier which avoids the whole
problem.

 
> Apparently you did not address the painful issues in printf
> compatibility (I did not look thoroughly, but at least you implemented
> the '0' flag by using '0' as a fill character, which is not enough)

No, though I don't know if I should.  That would be attempting
to graph functionality onto iostream which it simply lacks.  
I think it would be better to point those out as deficencies of 
iostream.  

Adding functionality to format which isn't in iostream like truncate
creates the problem that you would need to make a new set of manipulators
which only work with the format and those have to be seperated out.

  cout << format("%s" , group(truncate(10),long_string) );

Thus we get the big problem now how do we get truncate to format
and not to the ostream.  Ugly!

When I first proposed format class, I hadn't ever intended to
try to get all of the quirks of printf as it would make the 
code bloated and cause more interactions that I would want.

Additionally, you can't try to graph them on when using unknown
types.

Ie.

  cout << format("%#0x" , complex<int>(20,21) );

If you use fill you get 0x in the wrong place, if you add it 
yourself you will find the imaginary part is misformated.  
This simply points out how defective iostream is that it
can't replicate such a simple function as minimum number width.

 
> > Documentation to be added after initial feedback.  
> 
> I'm not sure to understand why you plan to write documentation.
> Should I be understanding that your submission is designed as another
> candidate to become boost.format, rather than to demonstrate the
> feasability of different approaches  ?

There has never been any policy against submitting something 
even if something similar has already been approved.  Code 
replication in free software allows expression of alternative and
potentially better designs.  

> That's fine with me if you want to build a concurrent candidate, but I
> thought elections already had accepted the current pre-version of
> Boost.Format, that I have to finalise and submit for final acceptance.
> Until my final candidate is submitted to vetoes, I'm taking all advices
> and critics to modify the library. And indeed the debate was still very
> active in the last few days on both the syntax issue and the method to
> use for passing arguments (operator%, '<<', [], .with( ) ...)

Certainly.  

> I'm reading your code with interest, but for now it might be better to
> share your critics, and suggested modifications for the current
> candidate, rather than to duplicate efforts.

I needed the class for a project anyway and the current submission
just wasn't up for my personal taste.  Since I had a code base 
already for most of the meat and such it wasn't much of a replication.
Besides if the new parse code turns out to be nicer that the
old you can certainly transport it.

 
> I plan to upload the final submission within a week, so people should
> not have forgotten everything about the library by then.

Highly unlikely to be forgotten considering the apparent level
of interest.  There is even another one located on freshmeat.

--Karl