Boost logo

Boost :

From: Karl Nelson (kenelson_at_[hidden])
Date: 2002-01-29 12:51:54


> > From: Karl Nelson [mailto:kenelson_at_[hidden]]
> >
> > #4 can't be optional as you need an end tag. Printf is well designed
> > in that the start flag % must have an end tag. However it is
> > problematic in that the string almost must be parsed backwards as the
> > meaning of precision and width vary.
> >
> > I don't want to reinvent printf though as as has been pointed out
> > dozens of times printf is the standard that outside coding firms
> > are most likely to use. Thus conformation is good.
>
> I don't think that there is any need for a printf-legacy vs. modern-syntax
> debate. There is no harm in having a class that provides backward printf
> compatibility for those shops that desire it. This is good, since opinions
> about what coding firms will be using in the future are highly speculative.
> It depends which technologies win out. If .NET gets huge, its format
> specifier may become the one most likely to be used. (I just took a look at
> MS's [1]. I found interested that they chose to go with a zero-based index
> for the position.)

Any pointers to their format string?

 
> The interesting discussion at hand is what can we do with a printf
> *replacement* (as opposed to a reinvention, which tries hard to keep
> backward compatibility). As such, we focus on areas where better end
> results are available by if we are willing to leverage a design that
> diverges from printf's.

Well if you stick with %blah anything <endtag> you can make a
format which accepts both. I really don't like ones like
%p1$s which "looks like but isn't". Extensions like %{blah}
are more palatable.

> > You should not have to specify the order of the argument by default.
> > It would induce errors to do so. After all when the programmer writes
> > it they will write. "My dogs name is %s" Reordering is a low
> > level feature not used often excepted in translation.
> >
> > People keep putting to high of emphasis on the reordering which
> > really is only rarely used. In printf format is a optional arguement
> > used in secondary strings only. How often is a coder going to
> > really write "[2] has [1] balls" rather than just reversing the
> > arguments in the code?
>
> I agree that reordering is not often necessary. It does have the advantage
> of uniformity and readability. Readability is in the sense that if a
> programmer wants to see what parameter maps to a given placeholder, he
> doesn't need to parse the preceding portion of the context string and count
> the number of placeholders. Small deal, but so is putting the 1 and 2 in
> "[1]" and "[2]". A syntax that let the programmer choose his preference on
> this tradeoff would be desirable.

This gets a lot harder when you start throwing in manipulators unfortunately.
That is why I am switching to a groupable format like...

  cout << format( fstr, 1.0, group(hex,width(10),16), "bob");

rather than

  cout << format(fstr) % 1.0 % hex % width(10) % 16 % "bob" ;

In the first the positionally nature is there. Plus you can now
see the manipulators are only to the one argument.

It also is good in that you can group arguments in reasonable ways...

  cout << format(" Change is %d", group( c>0?'+':'-', c) );

Thus both the char and the int get placed in the position 1.

> > Well I will submit my revised formating tool shortly. Hopefully
> > it will help the debate by giving an alternative. I am however,
> > going to go with the flow and submit it with syntax
> >
> > cout << format( fstring, a1, a2, a3 ) << endl;
>
> I'm looking forward to it. There's nothing like a concrete example.

Will do.

--Karl


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