Why didn't you go with MACRO-less solution?
Because it is a non-standard way of doing things. The majority of boost libraries use macros to control compilation.
So what? I couldn't comment on the case where boost libraries use macros, but if there is a way to do without, why not?
1. Logging Policy
This policy supposed to be responsible for *how* you do logging (not what or when).
That seem unnecessarily inflexible. How can you determine in advance what should be logged and when it should be logged? Also, why do you say "supposed to"? What are the specific reasons why the logging policy design is flawed.
I couldn't. But most importantly I shouldn't. PBD is not about providing single logging policy that do everything related to logging. PBD is about providing orthogonal (independent) policies each one with specific responsibilities. In this case Logging Policy responsibility is to define "how to do logging". Collection Policy defines what to log and Reporting policy defines when to log. Each one independent and easily substituted. If you policy responsible for everything and you component is just hollow forwarder, then such component doesn't bring any value and in most cases it would be easier to write custom component itself then custom policy. Yes it is not simple to design PB component that both flexible to cover most important cases and is not hollow so that it has real value. With proper design every policy has specific responsibilities with specific interfaces related to these responsibilities, while you component orchestrates policies interactions.
I give the option to the user through the policy. I could separate the logging policy into three separate policies: when_to_log_policy, how_to_log_policy, what_to_log_policy. But it is to simple to warrant this extra refactoring IMO.
You already have other policies responcible for these tasks.
Accordingly it shouldn't be event driven. It should be ... feature driven: log_start(...), log_finish(...) e.t.c. I don't really understand how you intend to use your current interface.
I don't see how this confusion could arise given the simplicity of the design. Could you ask a more specific question?
Simplicity of design doesn't make it correct.
2. Stats Policy From you docs (emphasis is mine): "The stats policy is responsible for collecting *and* reporting statistics". Did you notice 'and'? You still trying to put two eggs into same basket.
The collecting and reporting of statistics is inextricably linked. You can only report stats that you have collected. I do not see how you could separate the two.
Collecting is responsible for WHAT to collect. Reporting is responsible for WHEN to report. I do not see why would I want to unit them into single concept.
What if you want 2 different profilers, both scoped, but first measure wall-clock time, second measure process time?
That is beyond the scope of the library. I can not imagine a profiling tool which would want to measure wall clock time. The profiler library measures time durations only.
There are different kinds of time duration and different ways to measure it. Wall clock time is as good anything else. But even with process time, I may want to measure clocks or user/system time separately.
3. Timer concept I am not sure that boost::timer interface present the best abstraction for Timer concept.
However it is what we have to build off of. There was a lot of work that went into it, and I am confident in the design decisions that were made. I also like the simplicity of it.
Where did you get your confidence from? Does your design passed through challenges presented in variety of possible profilers out there? Simplicity is good until it cause inflexibility.
Among other things I believe you also need time_type (long, long long, int64_t, timeval e.t.c). Also using double for elapsed in general may not be desirable also.
I agree that this would make it more powerful, however it would also give a false sense of security w.r.t the robustness of the tool. I don't want to spend an inordinate amount of time dealing with the quirkiness of timers. It is a very complex subject, and virtually impossible to do both portably and correctly. I believe that what was good enough for boost::timer, is good enough for boost::profiler.
The thing is that boost::timer is not good enough for many non-trivial profiling tasks (and it was discussed here on ML many times). Overflow is one of the major issues for example. So without larger time type you couldn't get around it's deficiencies. I do understand that you do not want spend time/effort more on this, but don't expect us(me) to blindly agree to what you have right now. Regards, Gennadiy