Boost logo

Boost :

From: Brey, Edward D (EdwardDBrey_at_[hidden])
Date: 2002-01-29 12:17:31

> From: Stewart, Robert [mailto:stewart_at_[hidden]]

> Perhaps I misunderstood your original question, but here's
> what I was trying
> to say:
> Format 1: 1,00,324,54.00,123
> Format 2: 10,032,454.00123
> These two ways of representing the same number require
> different widths. It
> may, then, be necessary for a translator to specify the width
> and precision
> values differently for the two formats, so the width and
> precision would
> need to be part of the format string.

Agreed. The width and precision would go into the format string in this
case. And the format string always overrides the manipulators, if any. My
point is that the following example does not need to be supported, since it
would be quite rare:

format("[1[2]] [3[4]]"), value_a, width_a, value_b, width_b);

Where a translator my want to replace the format string with:
"[1[4]] [3[2]]" // never actually needed

I.e., the following would be fine:

format("[1] [2]"), manip(value_a, width(width_a)), manip(value_b,

(I'm ignoring details of syntax for the point of this example).
The central idea is that the width is either in the format string, in which
case the translator has carte blanche, or is programmatic, in which case it
is always bound tightly to a single parameter (or persisted across all
subsequent parameters). There is never a need for change of binding of a
programmatic width in the format string.

> There's no need for tab stops or alignments. The available
> width is divided
> into regions based upon the number of spring tabs, then the
> text is inserted
> into those regions with specific overflow rules.

Neat. The width of the region still needs to be provided, right? And
wouldn't there be some cases where it would be handy to hand-specify the tab
locations? This reminds me of HTML tables. It also points out a fuzzy
line: When does format go too far such that it becomes its own mark-up
language (i.e. Lynx in library format)?

Boost list run by bdawes at, gregod at, cpdaniel at, john at