Boost logo

Boost :

From: Hendrik Schober (boost_at_[hidden])
Date: 2001-11-14 17:03:58

<Msk_at_[hidden]> wrote:
> [...]
> 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
> unicode.

  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
  for both.)

> 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)
  is enough.

> 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
  parameters inserting.
  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.

> Have
> 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, gregod at, cpdaniel at, john at