RE: [boost] Review : format2, yet another 'printf class'

From: Samuel Krempp (krempp_at_[hidden])
Date: 2001-07-02 12:33:26

> Not me :). I don't like the idea of full-fledged support of printf format
> directives at all; conversion characters (type indicators) are unsafe,
> non-extensible and error-prone at best, they are not technically needed,

in my class, they _are_ type safe.
cout << format("%p1$x") % n;
is strictly equiv to
cout << hex << n;

so n might be a custom type with a pair of long int, or floats, or a
string, whatever.

my rationale with printf directives is
1. accept format-strings designed for printf,
   and in the cases where printf's behaviour is guranteed (good arguments,
   etc..), the result of printf and that of pformat should be equivalent.

2. beyond printf usual field,
   use its syntax to express formatting option,
   where the flags' meanings are their most natural interpretations :
   example : range = make_pair<int,int>( n1, n2);
             int i;
             cout << format("%p1$4x %2\n") %range %i;
         will do the same as
             cout << hex << setw(4) << range << dec << setw(0)
                << " " << i << "\n";

   lots of printf flags, whose aim is telling printf what will be the
   type of the arguments, are thus ignored by format.
   But some (width, base, padding,..) are still useful.

> it's clearly not a C++ way of doing things, and including a support for them
> is like bringing to life a dead person that most of the people prefer to see
> dead :). Flags and precision specifications are type-dependent (and
> therefore error-prone) too, and, personally, using the libraries that

they may be, but anyhow, they are sometimes needed !
what do you care if someone sets the precision when printing a
string ?
obviously precision flags have no effect when they are not pertinent.

> require you to learn some fancy small "language" (even if it has managed to
> become a standard one) have never been a pleasant experience. In some sense,
> of course, iostream manipulators form a "fancy small language" too, but for
> me there is a big difference between '-' and 'left' (or 'align_left').

for me there are 2 big differences :
1. left is a natural language word, so not too hard to remember.
2. left makes for long typings : << left << x << right is lots of letters
   vs "-"

one goal of the format class was precisely to bring printf's concision to
the nice type-safe world of streams, wasnt'it ?

we should not be ashamed of printf and want at all cost to ban its syntax.
It was designed to cover most useful common desires with a concise syntax.

and BTW the syntax is not so complicated, when you take away all of the
unused type-specification.
I began writing a description of format's syntax in Readme.txt
so that people can have a quick reference specifically written for
format.

> formatting/type specifications seem much more like a weakness that is not
> worth to be replicated ;).

[type-specification, once again, does not apply to my class's
formatting..]

I dont see what you want a format class to do..
we already have streams for sequential output  with no special formatting
options.

> > I am willing to sacrifice terseness and live with
> > %1%, %2%, etc if there is no better alternative.
> > I don't like it, but would live with it.
>
> I don't like it either, and I would prefer the short form (%1, %2, etc.).

okay, once again, the short form is and from now on will ever be,
supported.

> Finding a good syntax for specifying the formatting of arguments (not
> embedded into format string) can be hard, though.
 ^^^^^^^^^^^^^^
I dont understand this. The goal of class format is precisely to
deal with strings indicating  formatting ..

-- 
Sam