RE: [boost] String formatting library: interest?

From: Glew, Andy (andy.glew_at_[hidden])
Date: 2002-05-30 14:44:26

> - Way easier to localize: you don't have billions of little 
> strings to put in your resource-only files, and the translator won't go 
> crazy trying to re-construct the sentence from little pieces.

Positional vs Names
================

Having worked in translation, I second Giovanni's observation that

        string name = "Billy";
        string unit = "kilograms";
        int weight = 29;

        cout << fmt("%3's weight is %1 %2").arg(weight).arg(unit).arg(name)

is easier to translate than

        cout << name << "'s weight is " << weight << " " << unit;

But even easier is the non-positional version:

        cout << fmt("%name%'s weight is %weight% %unit%")
                        .arg("%weight",weight)
                        .arg("%unit",unit)
                        .arg("%name%",name)

viz

        cout << fmt("Le poids de %nom% est %poids% %unites%")
                        .arg("%poids%",weight)
                        .arg("%unites%",unit)
                        .arg("%nom%",name)

I suggest supporting the non-positional form with named substitutions,
with the positional form as a shorthand.

.arg()
====

I don't care about + or * vs .arg(..) ---- well, actually, I do care, I
deprecate
operator overloading myself.  But marginally.

string vs. stream
=============

there are good reasons for both string oriented formatters and stream
oriented
formatters.

string oriented formatters are IMHO more convenient and easier to use and
(re)define.

stream oriented formatters are useful when it is possible that the object's
string
representation is too large to fit in computer memory (but not so large,
e.g.,
that it will fit on disk).

They should be interconvertible.  I.e. if you have 
stream& operator<< (string&, TYPE arg)
then a to_string(TYPE arg)
should be automatically definable, and vice versa.
(I spend far too much time writing such stuff.)

Type Independent (Numeric) Formatting
==============================

Now, let me pitch my current annoying bugbear: 
I trust that you understand that some of us need
more than the default control of numeric formatting.
E.g. we need to be able to say the equivalent of
printf codes
        float f;
        fmt("%6.2f",f);
or
        int i;
        fmt("%10d",i);
        
        uint32_t u32;
        fmt("%08x",u32);

        uint64_t u64;
        fmt("%016llx", u64);
        fmt("%08llx",u64);
        fmt("%lld",u64);

I have a problem with the last:
the fact that in standard C printf 
I need to change formatting characters
to correspond to the type of the parameter
passed in.  Which creates a hassle when
you change an address from 32 bit to 64 bit,
or if you change a coordinate from 16 bit
fixed point to floating point.

I.e. embedding types in the formatting code 
is bad. The formatting code should just contain
the output specification.  (Not to mention the problems
that ... varargs causes.)

Sure, ANSI C has standard macros for
"the formatting string that you use to print a 64 bit 
integer in hex", but they are a real pain to use.
At the least, they need to be embedded in a type traits.

Better if they are totally hidden from the user.

So, I plead for the formatting codes of your string
formatting library 
        (a) existing, with at least printf like abilities
        (b) being type independent
- e.g. so fmt("%d",x) works for integer x, float x, unisgned x, etc.,
and so that fmt("%08x",a) works for {signed,unsigned} {8,16,32,64}
bit integers.

===

Longer odds: COBOL /  PL-1's PICture formats (also some Basic)
are overall more powerful than printf.  I'd love to find a C++ library
that supported PICtures.