RE: [boost] Re: Thoughts on Format

From: Brey, Edward D (EdwardDBrey_at_[hidden])
Date: 2002-01-29 12:05:24

> 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.)

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.

> 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.

> 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.

[1]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfSystemStringClassFormatTopic4.asp