Re: [boost] Re: anti formatter

From: Karl Nelson (kenelson_at_[hidden])
Date: 2001-12-20 14:21:41

> Why not like this:
> 
> BOOST_START_FORMAT_DEFINITION( classic_date_format, 3 (int,int,int))
>  arg1 << '-' << arg2 << '-' << arg3 
> BOOST_END_FORMAT_DEFINITION
> 
> BOOST_START_FORMAT_DEFINITION( us_date_format, 3 (int,int,int))
>  arg2 << '/' << arg1 << '/' << arg1
> BOOST_END_FORMAT_DEFINITION
> 
> BOOST_START_FORMAT_DEFINITION( long_date_format, 3 (int,int,int))
>  day_of_week( arg1, arg2, arg3 ) 
>     << ' ' << arg2 << '/' << arg1 << '/' << arg1
> BOOST_END_FORMAT_DEFINITION

So this solves date, but how about every other language problem
which is likely to occur.  Many languages don't have the same 
word ordering that as English.  You can't possibly make macros
to cover all of them.  

Look over http://www.iro.umontreal.ca/contrib/po/HTML/gettext.html
to see what other languages do and thus why C++ should provide
something similar.

printf (gettext ("String `%s' has %d characters\n"), s, strlen (s));

printf ("%2$d Zeichen lang ist die Zeichenkette `%1$s'", s, strlen (s));

Considering the string is most likely provided by outside translation
firm who knows nothing about your code how would your approach handle
the above?

> The third format you wont be able to implement using fixed prinf 
> syntax.

  cout << format("%d%s%d%s%d") << day << data_separator << 
                               << month << data_separator <<
                               << year;

This can be arranged for d-m-y, m/d/y, dd-mm-yyyy, anything
just by translators with outside string database.

 
> If format is compile time decision you can use typedef:
> typeef us_date_format date_format;

Compile time translation means providing seperate binaries for
i18n programs.  This to me is very bad. 

 
> > This is a powerful thing to offer translators. This sort of 
> technique is
> > extensively used on some projects that use gettext as their 
> translation
> > system, and the need to substitute in a different order comes up in 
> many
> > translation contexts, not just with numeric or date formatting.
> > 
> > Note that ostream formatting is already pretty good. The formatter 
> proposals
> > appeal to me because of:
> > 
> >     1) reordering capabilities for translators on projects that 
> translate by
> > string
> 
> I can provide not only reordering capabilities

More than reordering is boardering on the problems like plurals and
gender specific articles "la casa".  Those problems are beyond the
scope of what a formatter can do.

> >     2) more-terse way to specify format
> 
> My way is not terse enough?

Not for the more general problem than dates.
 
> >     3) easier to decipher the format because it's "by example" -- 
> the format
> > looks something like the final result
> 
> My way is not easy enough?
> 
> >     4) translators on projects that translate by string can easily 
> alter
> > format specifications like precision or padding
> 
> So do I.

I don't see that in your approach.

 
> >     5) syntax familiar to the many programmers who already know 
> printf
> > format, but without type safety problems inherent in printf use
> 
> But unfamiliar to any iostream user.

I don't see how an iostream user can ignore printf.  There are
things don't with printf which otherwise take many lines iostream
code.
 
--Karl