Re: [boost] Re: Boost.Assert

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 
  developers.) 

> - 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

  Schobi