Dave Jenkins wrote:
"David Abrahams" <dave@boostpro.com> wrote in message news:m28wmbf91i.fsf@boostpro.com...
on Tue Apr 07 2009, "troy d. straszheim" <troy-AT-resophonic.com> wrote:
Gevorg Voskanyan wrote:
How about a macro BOOST_PROTO_EXTRA_CHECKING or something like that to have those kind of checks conditionally?
I could see a BOOST_MPL_DISABLE_ASSERTS token, behavior analogous to BOOST_DISABLE_ASSERTS.
It's a very good idea, IMO. Open a ticket?
This flag sounds the same as the BOOST_COMPILE_TIME_DEBUG flag proposed by Eric Niebler here: http://lists.boost.org/boost-users/2009/01/44451.php. Joel de Guzman suggested making it an integer (0 == no CT debug, 1..3 CT debug levels) here: http://lists.boost.org/boostusers/2009/01/44452.php.
My thought is to have one of the integer debug levels enable compile-time tracing of "interesting" template instantiations using Steven Watanabe's template_profiler. For this to work, the library author would have to mark the "interesting" template classes and functions with "PROFILE_TRACER()" and bypass Steven's preprocessing stage. Is this workable and/or a good idea?
Interesting ideas... At first glance it still seems to me like stuff that belongs in the MPL. I could see an MPL_TRACE() macro that expanded by default to nothing. The user could set it as appropriate to use Steven's tracer or some future tracer, for instance one built in to clang. I'm not sure I agree with the debug-levels idea, as these are asserts, not warning severity levels. If they were warnings, it is still difficult to coordinate between developers, ie I don't really know if I'm using level '2' to mean the same level of 'debugginess' as somebody else is. It is also impossible to enforce. In the case where debug levels are going to regulate the number of traces you see, I don't see that as very useful either, since when tracing template instantiations you're dealing with a spectacular amount of compiler-spew no matter what. Now, per-class trace control (maybe via a trait?) this would be imho more useful. -t