[boost] Re: minor scoped_ptr/scoped_array feature request

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2002-11-17 13:45:28

On Sun, 17 Nov 2002 12:53:52 -0500, David Abrahams
<dave_at_[hidden]> wrote:

>Not all preconditions are effectively checkable.

How true! :-(

>
>> Moreover, if you put the precondition in the library, you take the
>> burden away from the client
>
>No you don't. Either it's a precondition or it's not. If the library
>documents behavior in case of a "precondition violation", it's not a
>precondition anymore. The client can call the function and reasonably
>expect the documented behavior.

Yes, we had a similar discussion on c.l.c++.m:

http://groups.google.com/groups?selm=7dc3b1ea.0208140519.681ef2d4%40posting.google.com

Note that the emphasis there was on exceptions. For asserts, since
they "go away" with the "official program" (when NDEBUG is defined)
the official version of the function has still preconditions in the
meaning you give to the word. In fact I lean towards leaving
everything as is, because I don't think having duplicated asserts in
debug mode is a problem, however I would also like to hear if there is
something good in documenting the asserts in debug mode, as I said in
my other post. What do you think?

>>  this is highly recommeded since it encapsulates commen code _one_
>> place, not O(n) places!
>
>You can always add wrappers that add the checking you desire, and more
>importantly, implement some useful (to you) response to a failed
>check. However, there's no way to take away checking if it gets put in
>the library, and there's no way to change the response in case of a
>failed check if it's not the response you need.

Yes. I suppose you are thinking to the "release mode" though, right?
Because in the other case you already have the asserts on the library
side. What were you thinking to concretely? Logging to a file?

Genny.