Re: assert_handler?
Geoff Carlton wrote:
Thorsten Ottosen wrote:
frege wrote:
> Has there been any talk about increasing support for debugging in the
> next C++? In particular, things like extending assert, adding trace()
> (or output_debug_string() or whatever).
The answer is "yes"! Check out
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1962.html
The paper mentions enabling and disabling precondition checks as a
client side decision. I'm not sure I follow how this would be achieved,
for static or dynamic libraries.
The normal mode of operation will be to expand the precondition inline
at the call site. So the precondition does not need to be part of the
object code in the library (dynamic or not)
Also, what about within a single project? In a release build we may
want to skip precondition checks for an internal matrix class, but keep
them for high level classes.
This could be achieved by labeling preconditions with appropriate build
settings:
precondition "debug|safe_release" { .. }
Another idea would be labeling with a logical category that can then be
switched on or off:
precondition "internal" { .. }
precondition "scripted" { .. }
Regardless of how it is done, there seems a fundamental division between
preconditions that should always be enforced, and those that act as a
consistency check between internal classes.
Both your ideas are ok. We have been thinking much about this issue, and
it is partly a compiler-thing (the compiler may give you various options
for enabling assertions) and partly a language thing. We have been
thinking of something along this:
T& vector<T>::operator[]( size_type at )
precondition
{
at < size(); [["std.range_check"]]
}
T& binary_search(T* first, T* last )
precondition
{
is_sorted(first,last); [["std.debug"]]
}
Different librarries can flesh out their own levels of assertions, eg at
boost we might have
"boost.debug"
"boost.range_check"
I think 2-3 levels will satisfy most people's demands.
There is also the possibility of saying
!precondition
{
// critical code
}
-Thorsten
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]