Re: anti formatter

From: rogeeff (rogeeff_at_[hidden])
Date: 2001-12-20 14:04:57

--- In boost_at_y..., Darin Adler <darin_at_b...> wrote:
> On 12/20/01 10:12 AM, "rogeeff" <rogeeff_at_m...> wrote:
> 
> > Why? Any literals inside format definition could be extracted into
> > resouce files. Or do you mean something else?
> 
> I meant that translators often need to rearrange pieces of a 
message. In
> English the name of the file might come before the size, but in 
some other
> language the size might need to go first, or be repeated.
> 
> This has been discussed in the formatter thread, but perhaps you 
didn't
> follow that part. A classic example is this:
> 
>    printf("%04d-%02d-%02d", year, month, day);
> 
> A translator can localize this to US "mm/dd/yyyy" format with the 
Unix
> extensions to printf by changing the format string to:
> 
>    printf("%2$02d/%3$02d/%1$04d", year, month, day);
> 

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

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

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

Now to make them interchangable in runtime you can have an absrtact 
base class date_format. So the usage will be like this:

date_format const& df = get_date_format( year, month, day );

std::cout << df;

> 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

>     2) more-terse way to specify format

My way is not terse enough?

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

>     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 understand that you haven't seen the need for something like the 
proposed
> formatter, but I know many C++ programmers that would benefit from 
it for
> one or more of the reasons above. So I'd like us to iron out the 
details and
> get something into boost.
> 

And still don't.

>     -- Darin
> 

[...]

Gennadiy.