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

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2001-07-02 11:59:54

Samuel Krempp wrote:
> I was wanting to provide this very short style if at all possible.
> So well, I separated clearly short-style from printf-directives,

Cool :)

> and provided wrappers around printf directives
> ( say %xxxx is a printf directive, you can use it in format, 
> of course not directly, since it collides with %N,
> but via "%pxxxx"  , or "#xxxx"  - # is the new replacement for $..

Well, leaving aside my dislike of printf :), I still don't think that
allowance of two _so_ different in complexity and error-proneness forms of
argument specification is a good decision. IMO, if there is a need for
supporting extended printf format, a separate 'pformat' class (and only it)
is a much better way to do it.

[snip]
> 
> Also, the possibilty to store format objects, like :
>     format formatter("%1 %2 %3 \n");
>     cerr << formatter.print() %1 %2 %3;
>     cerr << formatter.print() %-1 %-2 %-3;
> 
>     assert( (formatter.print() %-1 %-2 %-3).str() == "-1 -2 -3 \n");
> 
> ( I'll try a loop of those and compare efficiency of this to 
> re-parsing the string each time.. might not be very compelling, 
> but well...)
> 
> if you dont use print() but applies the arguments directly, the
> formatter is modified at each call of operator%, so it works only for
> the first line (normal) Next time, you get an exception as soon as you
> feed arguments to the formatter.

Ouch! :) 

[snip]
> The alternative would be to design a formatter class so that
> you dont need to call print() :
> format_launcher   printer("%1 %2");
> cout << printer %x %y;
> cout << printer %380 %340;

This seems much better to me. 

> for this to work, I only need to provide a special operator% to
> the formatter class, which does :
> . create a format obect from the data stored in formatter
> . calls operator% on this format object.
> 
> But I dont think it is worth the extra code and complexity.

I think it does. I don't like getting exceptions as an answer on something
that could be catched (or prevented) at compile-time.

Aleksey