From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-29 11:52:20
From: Brey, Edward D [SMTP:EdwardDBrey_at_[hidden]]
> > From: Stewart, Robert [mailto:stewart_at_[hidden]]
> > > Do we need to put the width specifier in the placeholder at
> > all?
> > > [...]
> > I'll posit a situation that may not match reality, but, then
> > again, maybe it
> > does: when translating the format, it may be that the format for the
> > alternate language requires a different width. For example,
> > when formatting
> > a number with separators, don't some languages put separators
> > after two
> > digits in some places and three in others? Translating among such a
> > language and one that always puts separators after three
> > digits would change
> > the width in some circumstances.
> I'm having a hard time following this example. It doesn't seem to
> that programmatic widths can affect various placeholders by translation.
> Perhaps the example is indicating that it is important for the placeholder
> to override a manipulators width specification.
Perhaps I misunderstood your original question, but here's what I was trying
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.
> [Spring tabs]
> I like it. This could really make the outputting debugging tables a
> It would leverage well format's stateful behavior, too. I'd like to find
> syntax that minimizes the number of character sequences that would need to
> be escaped. Do you have a syntax proposal for how to specify the tab stop
> locations and alignments?
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.
Susquehanna International Group, LLP
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk