Re: [boost] Alternate Format Mechanism

From: j.adelman_at_[hidden]
Date: 2002-02-12 14:25:27

Quoting Karl Nelson <kenelson_at_[hidden]>:

> > > Second suggestion.  
> > > 
> > > Don't use "%1" this is too easily confused 
with 
> > other 
> > > formats ie.  Is this a printf format or 
yours?
> > >    I see %1s.
> > > 
> > > Use [1] (boost suggestion) or {1} (.NET).  
Also 
> > this avoids
> > > the ending tag problem.
> > 
> > That sounds reasonable; this was just my 
default 
> > choice because it had been used a lot, rather 
> > than a thought-out decision.  Alternatively, 
I 
> > could make this a parameter with a default, 
but 
> > this may add too much complexity.  I could 
also 
> > add a means to specify the format as a 
> > vector<int> & a seperation character, for if 
> > there is a non-translation use.  One thing 
I'd 
> > like opinions on is whether 0-based counting 
is a 
> > good thing, or should be replaced with 1-
based 
> > counting.
> 
> Most systems I know of are 1-based.  
>   - C printf
>   - awk  ($0 means whole string)
>   - perl 
>   - shell
> 
> I suspect python is 1-based.  I can't find .NET 
page right now.
> 
> I am sure a number of others.  
> Arrays start from zero because there is no 
offset for 
> the first element. That argument does not apply 
to something
> like formatting arguments.   History generally 
seems to favor
> 1-based.  However, if you are going to be 
indexing those arguments 
> to the user interface it would be compelling to 
use 0-based.
> 
> --Karl

I hadn't thought of allowing indexed access to 
the stored strings.  I didn't really expect the 
user to see anything except the reorder object 
which doesn't have any link to the underlying 
buffer.  What would such functionality be used 
for?

James

-------------------------------------------------
This mail sent through UK Online webmail