Boost logo

Boost :

From: Valentin Bonnard (Bonnard.V_at_[hidden])
Date: 2000-08-21 12:53:33

On Sun, Aug 20, 2000 at 08:05:13AM -0700, Karl Nelson wrote:
> > --- In boost_at_[hidden], Karl Nelson <kenelson_at_e...> wrote:
> >
> > > Streams have a bad tendency to cause pieces by breaking up text.
> > > This presents a problem for translation as phrases often
> > > must be translated as one unit with gettext. Further, the use of a
> > > stream fixes the order of which variables will be displayed which
> > > makes translation extremely awkward for languages where the order
> > > does not match that of the original program. As a result most codes
> > > which are designed for i18n can't use streams.
> >
> > Indeed code using streams cannot be gettextified (is that the
> > right word ?)
> >
> > Instead of inventing a tiny formating language, rewritting
> > i18n-dependant things in it, just write usual C++, and
> > translate the _code_ itself.
> I am not inventing a formating language I merely allow
> use of the very common one with streams.
> cout << format("This is a test %d %s") << int(1) << string("hello");
> > There is no need to use gettext, just change the code reponsible
> > for formating and printing messages.
> >
> > You can do that:
> > - with conditionnal compilation (for the very old-fashionned :)
> > - with CVS branchs: one branch = one language (probably
> > quite complicated)
> > - or rather, by moving all the formating code (ie all calls
> > to iostream) into a DLL
> All of these are extrodinarily bad ideas.

The first one certainly is -- it there to show, by contrast,
that the third one is excellent. ;)

Seriously, you need to explain why the other two are
``extrodinarily bad ideas''.

> To favor maintaining
> a larger code base in which you must track changes over multiple
> banches over just setting gettext strings is ridiculous at its
> face.

Why ?

> I18n that way is an employment act for a really dull
> programmer. And moving code the a shared library (which is what I
> assmue you mean by DLL)

These are synonym for me.

> also increase code complexity.

In term of number of functions, yes. The algorithms are just as
simple (or complicated), only the modularity changes.

> Making branches for i18n would be strictly against GNOMEs concept
> of write once for all.

How do you write the strings once for many different languages ?

> Note, I am the library writter trying to
> provide tools to my users not the app writter.

That's my case too.

> If boost isn't
> interested the class will simply appear in my library, Gtk--.

If boost isn't interrested, then boost probably doesn't care
about where the class will appear.

> > > ostream.form().
> >
> > What's that ?
> Part of the standard which uses ellipsis.
> cout.form("This is a test %d %s",1,s.c_str());
> For some reason C++ implements a printf with all the
> flaws of printf rather than something like a positional
> formatter for streams.

For some reason I have never seen this function. Where is it
from ?

> > I have also implemented a class for positionnal args:
> >
> >
> >
> > Typicall use is:
> >
> > boost::format(cout, "Cannot $1 at $2:$3\nCause: $4\n")
> > << "frobnicate"
> > << "blaz"
> > << showbase << hex << uppercase << 10
> > << "no more foobars";
> >
> > Note that any formatter can be used.
> Okay then this is really odd because boost has another
> stream formater as well.

Boost has no formating class. People have uploaded things in
the vault.

> Which is what the rest of the
> discussion was about. Note yours is very much like mine,
> except mine uses printf indicators so I don't have to invent syntax.

I didn't invented a totally new syntax, I took a shell-like
syntax ($1, $*).

The ISO printf syntax is only about types and formating, my format
syntax is only about position. Different goals, different solution.

> Although if you read the doc on the code I sent, all of this was
> already explained. I merely sent an introduction so that
> interested parties know the scope of the problem.
> Whether using printf syntax is good or bad is open for
> debate.

printf syntax is bad because it only allows a limited number
of types; actually the fundamental reason why printf syntax
is bad is because it deals with types.

> Our code bases both have compatible ideas asside from
> the formatting string. The other one (search for "basic i/o"
> in the archives) is not compatible and uses template
> based proxy to get ellipsis behavior. Those obviously
> the conflicts between the three code bases will need to be
> reconciled.

Valentin Bonnard

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