From: Hendrik Schober (boost_at_[hidden])
Date: 2001-11-14 17:03:58
> I hadn't even thought about internationalization.
I'm a not a native English speaker. So the
apps I develop at least need to issue my
native language and English. ;^>
> For strings that are intended for asserts or exceptions,
> that would seem to be overkill. These strings are
> like comments, in the sense that they are only intended
> to be seen by the programmer - and we normally include
> comments in only a single language. Also, I don't
> believe that std::exception::what() will handle 21-bit
You're probably right. We just use the same
code for stuff that might be seen by the user
as for developer-only messages. (That's
because our exceptions and our logging is used
> Another issue is that no matter how sweet the syntactic
> sugar, internationalizing strings requires significant
> effort [...]
Probably. For the few (western) languages we
need, beeing able to shift around parameters
of a message (essentially by having them named)
> I can't emphasize enough how important it is for the
> notation to be terse, since good practice requires you
> to write hundreds or thousands of these checks in any
> large system.
For assertions we write
ASSERT( i!=0 );
That's as simple as it gets. (But we can write
ASSERT( i!=0, ERROR_PAR(x()) );
which will add an argument named "x()", with the
value returned by 'x', which won't be included
in the message as it might be seen by the user
(since arg "x" isn't asked for), but which will
be seen by a developer in the log output.)
> On the other hand, I think that a library to do the
> sort of internationalization of strings that you
> describe would be a great addition to boost. Let's
> add it to the Wiki "wanted libraries" list.
What I've done isn't really fancy. It's just
some string parsing to allow order independend
That must have been done numerous times. The
issue with it is to make it efficient and easy
to use at the same time. And, as I said, ours
is just efficient enough for us.
> Of course,
> to do it right it will have to take into account all
> the character-set/multi-byte/unicode issues.
I've never had to deal with this stuff.
> you looked at format2 in the vault/files area? This
> appears to be relevant, and it may even be what you're
> looking for.
No I haven't. I'll do tomorrow.
> Perhaps the things we're discussing here actually
> decompose into three separate libraries:
> - assert, to do what Peter Dimov has been describing
If this is to be used mainly for the boost
lib itself, then it should probably be as
simple as possible. (That is, no message
formating, only simple messages for the
> - diagnostic string building, to provide the syntactic
> convenience that I want for certain common and highly
> stylized usage patterns
I could provide some ideas here, if it's wanted.
> - internationalized strings, which handle the language
> differences you described
What I described falls into the former category.
I've never used anything but 'char' strings.
> Our system does something quite similar. We don't even
> call them assertions, because they always throw on failure.
> > The problem with what we have is, in a performance
> > critical application most of it probably won't do very
> > good. For us it has been performing good enough, so we
> > never invested the time to improve it.
> We never found performance to be an issue. Exceptions should
> be sufficiently infrequent (relatively speaking) that speed
> is just not an issue.
We use this for logging as well.
> - Michael Kenniston
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk