From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-02-10 15:08:06
----- Original Message -----
From: "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]>
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
>> 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.
> you policy responsible for everything and you component is just hollow
> forwarder, then such component doesn't bring any value and in most cases
> 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
> 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
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
>> 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
>> > 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.
>> 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?
> 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.
Object Oriented Template Library (OOTL)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk