On Thu, 10 Feb 2005 14:12:16 -0500, Gennadiy Rozental <gennadiy.rozental@thomson.com> wrote:
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?
why to do it? Is there any issues in using macros int this specific case? it´s easy to implement, provides the all or nothing inclusion control we are looking for, and most programmers will easily understand the code.
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 do agree with you about the fact that good PBD should provide orthogonal policies, but the fundamental use for PBD is to delay implementation details to when they are needed, allowing easy to create and mantain yet flexible and extensible implementation. IMHO two policies (one for timer and one for logging) is more than enough for a profilling tool, how to colect data, when to report it how to report it, what estatistical analisys should be used are all policies for the logging policy, not the profiler. Some simple reports like "foo() - 50% - 10 ms" are usualy more than enough for simple tasks. Let´s save the big guns for the big tasks ;)
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.
idem above
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.
but usually simplicity make´s it less wrong, IMHO.
2. Stats Policy <snip>
same as before KISS principle <snip>
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.
It doesn´t have to be "good enough" as long as it is able ot evolve to become good enough, one of the points in reusing software is to be able to enhance several components by enhancing just one of then. Interfaces is importante, implementation is secondary. As long as there something tha are able to report how many seconds elapsed from moment A to moment B it really don´t matter how it´s done internally. Sérgio