From: Samuel Krempp (krempp_at_[hidden])
Date: 2001-07-02 19:55:30
On Mon, 2 Jul 2001, George A. Heintzelman wrote:
> > 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 like this functionality; I suspect it could be very useful for
> complex formats. However, I think the logic expressed by the 'print()'
> call is not printing at all, but 'clear'-ing the formatting object,
> which has gotten bound to certain sets of arguments.
> One could argue that clear() should be invoked by the operator<< call
> instead, after printing of course, which leads to IMHO more natural
> syntax. There might be other problems that I haven't thought of here,
> but I would consider this.
at the time of my message, it was not possible to clear, so print() was in
fact a cloning..
I modified the way format stores the converted strings so that it can now
clear, and have the behaviour you proposed. eg :
format fmter("%1 %2 %3 \n");
cerr << fmter %12 %14 %14;
cerr << fmter %0 %1 %2;
Plus, it's possible to 'bind' arguments :
cerr << fmter %40 %50; // -> "40 18 50 \n"
fmter.bind_arg(2, 77); // overwrites 18
cerr << fmter %10 %20; // -> "10 77 20 \n"
I dont know if bind_arg is really required, but it feels like a natural
thing to provide if we allow users to manipulate formatters.
it's not making the class more complex.
one vector<bool> to know which argument numbers are bound, and that's it.
you can look in the source files to make your own opinion on whether or
not bind_arg is overdesign..
if so, I would take it away.
( btw the header should be much more readable now, as I read dave's
guidelines doc and applied them -as well as I could)
> A second issue -- if this functionality is going to be supplied, one
> ought to be able to set stickily formatting options on an argument. E.g:
> format formatter("%1 %2 %3 \n");
> Or some such syntax; and then have the second argument always set to 8
hum, why not.
my preference here was to set things like this inside the format string.
But there might be cases where you want to modify a formater before reuse,
just changing a width or so.
it's quite direct to implement. (one function, 4-5 lines long...)
But again, people might call it over-designing, no ?
if not, I'll do that.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk