Re: Boost.Assert

From: Msk_at_[hidden]
Date: 2001-11-14 13:02:49

--- In boost_at_y..., "Hendrik Schober" <boost_at_H...> wrote:
>   Once the "formatting a string"-problem is attacked, 
>   I'd rather have it solving the "do the same with 
>   respect to i18", in order to make it more usefull 
>   in general. The problem with other languages is 
>   that it might change word and argument orderings. 
>   With the above that's hard to do. 
>   We use a scheme which allows to do this: 
>    "A message with @(arg #1) and @(another arg)." 
>   You pass two arguments, one is named "arg #1", the 
>   other "another arg". We use this for exceptions
>     //NotFound: "@(type) @(key) was not found"
>     throw XFileSpecError( ORIGIN_HERE, CMessage(NotFound)
>                         + buildNamedParameter("type","folder")
>                         + buildNamedParameter("key",filespec) );
>   as well as for logging: 
>     LogMsg( ORIGIN_HERE, 
>             "Object allocated @@@(this), about to call @(foo())...", 
>             ERROR_PAR(this)+ERROR_PAR(foo()) );

I hadn't even thought about internationalization.
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.

Another issue is that no matter how sweet the syntactic
sugar, internationalizing strings requires significant
effort, and the whole point of my proposal was to make
the process of building a formatted string so easy that
average programmers can finish writing a validation
statement before they even notice they're doing it.
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.
 
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.  Of course,
to do it right it will have to take into account all
the character-set/multi-byte/unicode issues.  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.

Perhaps the things we're discussing here actually
decompose into three separate libraries:

- assert, to do what Peter Dimov has been describing

- diagnostic string building, to provide the syntactic
convenience that I want for certain common and highly
stylized usage patterns

- internationalized strings, which handle the language
differences you described

The three perform sufficiently different functions
that IMO they should be separate libraries.

>   Since all our software is event driven (and we don't 
>   write software where failure is disastrous), we 
>   decided not to abort on failed assertions. 

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.

- Michael Kenniston