On 11/25/07, Lars Gullik Bjønnes <larsbj@gullik.net> wrote:
Stefan Seefeld <seefeld@sympatico.ca> writes:
| Lars Gullik Bjønnes wrote:
Which brings be to a nother point: It is _very_ bad of a library to require of the application to define NDEBUG to work properly. (The application should be able to decide for itself how NDEBUG/assert should be used.) Ublas should stop using NDEBUG and create their own BOOST_UBLAS_DEBUG or similar and use that instead.
| Are you saying library code may not use the standard 'assert' macro, | then, at least not in headers ?
| I don't quite agree with your statement. In fact, whenever you are using | libraries that are mostly implemented in headers, it becomes very hard | to encapsulate behavior the way you seem to request.
Still, forcing the application to not be able to use standard assert as it'd like is not really acceptable.
Amen to that! We are using using ublas in some important production code and we have to compile the entire application with NDEBUG, even if we (and external libraries) have important assert code that we would like to keep even on a running system. Unfortunately the sparse vector functionality in ublas in 1.32 doesn't even compile with NDEBUG not defined (and even if it did it would have abissimal performance). I think that NDEBUG should only be used for checks that are meant for production use (i.e. they won't slow down your program more than 5%). I like a lot that boost::shared_ptr and boost optional assert when deferencing in debug builds, and the cost is so small that I like to keep it even for production builds. For example the standard libary I use doesn't force you to use the checked iterators variant if you build with assert on: you have to use another explicit preprocessor define.
And if I am not mistaken something similar to my imagined BOOST_UBLAS_DEBUG is used for almost all other boost libraries. (At the very least the do not use NDEBUG as a switch for anything) (I see that other libs also use NDEBUG/ASSERT, and think that too is bad. But for ublas the implications are a lot worse. 3 magnitudes of performace is not to shrug at.)
In my experience the use of assert (or BOOST_ASSERT) in all other boost libraries has been very well thought out. I never felt the need to explicitly disable asserting for a specific library for performance reasons. The only offender so far has been ublas. -- gpd