----- Original Message ----- From: "Gennadiy Rozental" <gennadiy.rozental@thomson.com> To: <boost@lists.boost.org> Sent: Thursday, February 10, 2005 2:12 PM Subject: [boost] Re: Re: Latest version of the profiler
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.
This is too general. Please state a specific problem with the current code.
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.
I would appraciate a specific use case which shows the failure of the current code, and how an alternative design specifically solves the problem.
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.
I was talking about the Boost.Timer not my own design.
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.
It is not a bad idea then to update the timer resolution. However, I find it strange that the expectations on the Profiler library would be greater than those placed on the Boost.Timer library. Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org