----- Original Message ----- From: "Rob Stewart" <stewart@sig.com> To: <boost@lists.boost.org> Cc: <boost@lists.boost.org> Sent: Tuesday, February 08, 2005 5:36 PM Subject: Re: [boost] Re: Boost Profiler Proposal
From: christopher diggins <cdiggins@videotron.ca>
Okay, so the general consensus has been quite consistent: - ability to turn off globally - pause and resume - As unintrusive as possible (no requirement of code reporting)
^^^^^^^^^^^ (When you get to the docs, be sure to write that as "nonintrusive.")
Good point.
- hierarchical reporting (optional)
I think perhaps the best approach then would be a macro library. I propose
That is the only way to turn it off entirely. :-(
the following macros:
BOOST_PROFILING_OFF // turns off the macros
BOOST_PROFILE_START(profiler_type, name) BOOST_PROFILE_STOP(name) BOOST_PROFILE_PAUSE(name) BOOST_PROFILE_RESUME(name) BOOST_PROFILE_EXPR(expression) BOOST_PROFILE_REPORT(name) BOOST_PROFILE_ALL(name)
A better scheme would be to provide a null profiler class that BOOST_PROFILE_START instantiates when BOOST_PROFILE_OFF is defined. Then, there can be empty, inline member functions so that the following code compiles away to nothing in optimized builds:
void f() { BOOST_PROFILER(type) prof; // code to profile prof.pause(); // code to ignore prof.continue(); // more code to profile }
I like this. What if we took it a step further and wrote something like: template<typename T1, typename T2> struct profiler : if_<profiling_on, basic_profiler<T1, T2>, null_profiler>::type { }; This would entirely remove the need for macros. What do you think?
I then will follow Gennadiy's suggestion of multiple policies:
basic_profiler<reporting_policy, logging_policy, collecting_policy, timer_policy>
In keeping with the rest, should the latter be "timing_policy?"
That would be better. Or maybe it should be just timer_t since it doesn't really behave like a policy. Thanks for the comments, Christopher