[boost] Re: Re: Boost Profiler Proposal

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-02-09 00:25:30

> > 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