Re: Review request : format

From: mfdylan (dylan_at_[hidden])
Date: 2001-12-19 23:51:21

--- In boost_at_y..., Samuel Krempp <krempp_at_c...> wrote:
> On Wed, 2001-12-19 at 22:09, Karl Nelson wrote:
> > The implemention I sent of format had no problems with extra
> > arguments.  
> > 
> >   cout << format("A %2$s %1$s") << s1 << s2<< endl;
> 
> > For good reason.  All extra agruments after the format 
> > became regular operations.   
> 
> that's the problem for me : it won't notice user's errors.
> The uer could mistype the format-string, eg hit "%" twice : "%%2$s" 
> I'd like the syntax to enforce the right number of arguments, no 
more no
> less. 
> My code raises exceptions in both cases.

Out of curiousity, how often do people work when all format strings 
known at compile time?  If they are supplied externally to the 
application (eg in a resource DLL, or a plain text file) then 
obviously you can't check or interpret them at compile time, but if 
you prefer to compile your strings into the application (hence 
producing separate executables for each language), it would 
preferable to have the compiler not only pick up format specification 
errors but compile the specifications as much as possible.
Given that the strings themselves often need to be edited by non-
programmers (eg translation companies), you still need some way of 
specifying them that is straightforward, I could imagine specifying 
them something like:

format_string<2> msg_file_not_found("File " + P1 + " is not in path " 
+ P2 + "!");
format_string<3> msg_matches_found(P1 + " matches " + P2 + " elements 
in " + P3);

Where P1, P2, etc were const objects of type param<1>, param<2> etc.,
and implementing the whole thing to be done as much as possible at 
compile time.  I started playing around with it but it gave me a 
headache (hey it's almost friday).  
Is there any desire for a largely compile-time solution?

Dylan