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,
> 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.
> 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.
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk