$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-31 10:20:55
--- In boost_at_y..., "Brey, Edward D" <EdwardDBrey_at_e...> wrote:
> > From: bill_kempf [mailto:williamkempf_at_h...]
> >
> > My own opinion is that generalized formatting is already handled
> > quite nicely by iostream manipulators any way (the only two
arguments
> > I've ever heard against this was that "printf" was more
intuitive,
> > which is true only for old C coders, and that the manipulator
> > approach was very verbose, but I could care less about that).
>
> Verbosity does make a difference. Fortunately, the difference can
be
> explained in terms other than the nebulous "intuition factor" or
> "convenience factor".
>
> It's a matter of engineering principle: locality of reference, as
applied to
> its impact on the programmer. With the printf-style, you get good
locality
> of the format text:
>
> "Task [1] will complete within [2] second(s)."
This is *NOT* printf-style formatting. This is solely syntax for
positional parameters, which I very strongly support. (And I could
care less if the delimiter string syntax is %1%, %1$, [1], (1), %001
or any other variant you want to throw at it.)
What I don't like is any attempt to retain printf's type specifiers
and to a large degree attempts to retain length, precision, etc.
specifiers.
> That is to say, it is easy to see the flow of the sentence, the
correlation
> between "Task" and "will complete", for example.
>
> With stream style, you get good locality of the variables to their
> surrounding text:
>
> "Task " << task_name << " will complete within " <<
> estimated_completion_time - current_time() << " second(s)."
>
> Here it is easy to pair "Task" and "task_name", for example.
>
> Each type of locality has its own advantage. There is a tradeoff,
and which
> style is best depends on the situation. In my experience, I've
found that
> when dealing with full English sentences, the locality of the
format context
> is most desirable, whereas for short, simple outputs, like those in
some
> trace logs, locality of a variable to its text is most desirable.
When speaking of locality, to me the important thing is to keep the
formatting code with the object being formatted. In other words, I
think that:
cout << format("[1]") << width(10) << foo;
is much preferrable to:
cout << format("[1:10]") << foo;
I think it's easier to read and comprehend, and it certainly will
make the translation of the format string easier.
Bill Kempf