Review : format2, yet another 'printf class'

From: Samuel Krempp (krempp_at_[hidden])
Date: 2001-06-29 03:36:09

A year ago, Responding to David Abrahams' challenge in msg 2379, a format
class was implemented by  Rüdiger Loos's, placed in the vault (as
'format') and discussed for some time.

Then (in msg 4582) Karl Nelson brought in his own implementation of such a
class, with different orientation
(http://www.ece.ucdavis.edu/~kenelson/ofrstream.cc)
Discussions followed, and msg 4634 presents a summary of the issues by
karl nelson.

Now, looking at those 2 classes, I implemented my own format class
and uploaded it in the vault as format2, and I'd like to get
comments on it, and eventually proceed to a formal review.

I uploaded (in msg.txt) a presentation to this class that I copy here,
but it is not intended as an introduction and the sample program (and the
header) are best read first.

-------
Usage :
-------
format( format_string )  arg1  arg2  arg3 ..
where each argument has the form :
       [ '*' mod1 '*' mod2 '*' ... '*' modN]  '%' var

mod1 .. modN are treated as stream manipulators,
That is : they are sent to the stream but dont count as an argument,
and their (potential) string output in the stream is discarded.

- there must be enough argument to satisfy the format string
 Note format(" %12$s ") % .. is legal (if followed by 12 arguments)
      whereas it is forbidden in Unix98 printf

- extra arguments are ignored (but are evaluated, of course)

--------------------
Format-string syntax :
-------------------

" ... %<x1> ...  %<xn> ..."

[ let's call x1 - xn "items",
 and call 'arguments' the variables given for display to format  ]

The syntax is compabile with printf's
 http://www.opengroup.org/onlinepubs/7908799/xsh/fprintf.html

items follow one of the following forms (that can NOT be mixed in one
string) :

%N$spec  to mean "print argument number N"
or :
%spec   which just selects next unused argument.

spec has the form :
[option] [width] <type> with :
-type in
    's'      :  print agrument
    'c'      :  ..
    'X', 'E' :  ..   in uppercase
    'p', 'x' :  ..   in hex
    'o'      :  ..   in octal
    'u','d'  :  ..   in decimal
    'e'      :  ..   in scientific float format
    'f'      :  ..   in fixed ..

-width is a number indicating minimal width of the string resulting of the
insertion of the argument.

-option in
     '-'     :  align on left
     '0'     :  use '0' as a fill character
     '#'     :  showpoint

---------------------------------------------------------

Issues (that I can think of) :
-----------------------------

0. we could define a completely new syntax, more adapted to the situation
   than is  Unix98 printf's syntax, and which would be more concise,
   and powerful.
   But keeping the same has its advantage.. so unless someone has a
   great syntax to propose, discussions had settled on keeping printf's
   syntax.

1. should we add features to the format string syntax ? like
     an option '^' to indicate centering, similar to  '-' for
     left-alignment.
     (this requires to have a first conversion to string, so as to know
     the size of output)

2. use of operator%, instead of operator<<
   I think it gives a nice way to group what *are* the argument to format,
   rather than having to put markers like :
   cout << format("bla bla") << x << y << endf << " and next, .. \n"

  but this is easy to change back to '<<' (just a slightly different
  design, not as straightforward as the current one)

3. In function signatures, I can not distinguish std manipulators from
   any other object..

   passing manipulators via operator*  is OK ?

   another option implemented is to encapsulate them inside a class that
   can be recognised, like that :
   % glue(setw(4)) % x
   the advantage for operator* is conciseness and better visualisation.

   Are there other ways ?
   Abrahams proposed format(" %d ") % hex(x);
   It requires to implement one function for each supported manipulator,
   but ..

4. errrr, uppercase flags 'E' or 'X' do not work here (g++ 3.1 cvs)
   but neither does
   cout << uppercase << "bla";
   g++ 's fault or .. ?

-- 
Sam