On Sun, 17 Nov 2002 12:53:52 -0500, David Abrahams <[EMAIL PROTECTED]> 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
