[guidelines suggestion] boost-wide debug support
Right now every library enabled and disables internal debug support individually. Its impossible to do it now from single place. Suggestion for guidelines: - If BOOST_NDEBUG is defined then all libraries will switch off any debug support (asserts, pre- and post-condition checking, invariants etc). There would be no exception. - If BOOST_DEBUG is defined then all available debug suport will be switched on. There would be no exceptions. - If neither of macros is defined then libraries will behave as they behave now - picking their own choice using library specific macros. This would allow fine grained customization. Enforcing this rule would require quite a lot of effort and cooperation though. For example all assert()s would need to convert to BOOST_ASSERT()s. /Pavel
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> writes:
Right now every library enabled and disables internal debug support individually. Its impossible to do it now from single place.
Suggestion for guidelines:
- If BOOST_NDEBUG is defined then all libraries will switch off any debug support (asserts, pre- and post-condition checking, invariants etc). There would be no exception.
What about static asserts (which cost compile-time resources)?
- If BOOST_DEBUG is defined then all available debug suport will be switched on. There would be no exceptions.
- If neither of macros is defined then libraries will behave as they behave now - picking their own choice using library specific macros. This would allow fine grained customization.
Enforcing this rule would require quite a lot of effort and cooperation though. For example all assert()s would need to convert to BOOST_ASSERT()s.
That seems like a small price to pay if there are significant benefits... but are there? What's the motivating case for doing this? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote: [boost-wide debug macros suggestion]
What about static asserts (which cost compile-time resources)?
This is completely different and orthogonal. No need to change IMHO.
That seems like a small price to pay if there are significant benefits... but are there? What's the motivating case for doing this?
It is next to impossible to switch on debugging everywhere if something goes wrong when one needs all the support that's available and quickly. Worse, one cannot be completely sure release build is free of debugging artifacts (unless lot of effort is spent on it). The benefit is increased confidence in the system, IMO. /Pavel
participants (2)
-
David Abrahams -
Pavel Vozenilek