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:
So do I.
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?
Yeah. It worth perusing.
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.
Actually timing_policy is not necessarily only timer_t typedef. It may also include time type (including arithmetic operations), precision values, max/min timing periods constants, e.t.c. So I don't think you may get away with just timer_t.
Thanks for the comments, Christopher
Gennadiy