Boost logo

Boost :

From: Samuel Krempp (krempp_at_[hidden])
Date: 2001-12-20 15:41:46


On Thu, 2001-12-20 at 18:48, Xtramax wrote:
> Obviously I did not read the specification with sufficient care to achieve
> understanding but I did read it with what IMO should have been sufficient
> care. This implies to me that there are too many options mixed up
> together.
>
> Perhaps it would be better to offer only two options :
> positional only :- %1 %3 %2
> and
> unix98 printf :- %1$s %3$u %2$s

it's true that it has the advantage of being quite clear.

Now I think what format needs to achieve this clarity, is to have the
doc presents things so that people who reads the doc very quickly
understand at leat one thing : there are 2 modes, one which emulates
printf, the other which aims at simplicity.

Once this is very obvious in the doc, a footnote at the end of the
'short-style' paragraph could tell the user that he can use printf
directives even in short-style mode by using %p<stuff>.
This footnote might be uneasy to understand in 5 seconds (but still
clearer than any given manpage, IMO :-), but the feature will be present
when needed.
eg if someone needs formatting on only one argument among 5, it is sad
to force him to use printf mode.

So I file this under 'Documentation defaults', all right ?

> I have implemented my own ( simple ) manipulator based formatting but I
> believe that your "string-building" approach solves most of the issues I
> have had with it.

Yes, it makes the code pretty straightforward. no reference-counting
anywhere, no need to return a proxy after the first cout << format(), ..
everyhting fits nicely.
It seems you, nasononv, and me all felt the same after trying a few
implementations.
On the other hand, Karl Nelson is convinced that the format object can
really be seen as a manipulator and implemented without issues.
I find it hard to pin-point what went wrong for me in the 'manipualtor
approach' when I tried it, though, thus I have difficulties defending my
choice..
If you have technical explanations showing the issues involved in the
manipulator approach, it could be useful for giving more facts to the
debate.

Best regards,

-- 
Samuel

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk