|
Boost : |
From: Sérgio Vale e Pace (svpace.forum_at_[hidden])
Date: 2005-02-11 08:25:39
On Thu, 10 Feb 2005 15:58:55 -0500, Gennadiy Rozental
<gennadiy.rozental_at_[hidden]> wrote:
> > 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,
>
> It's only a side effect. Fundamental reason to use PBD is to introduce
> granulation into your solution moving toward: one entity - one task
> principle
indeed, breaking a big and ugly task into a set of smaller,
self-contained and simple mini-tasks has been one of the main porpuses
of almost all programming techiniques since before the fortran guys
first walked on earth, the main issue is how do you acomplish that.
PBD is about customization and separation of concerns, otherwise you
could just hardcode your policies in the object hierarchy, avoiding
templates all together:
class profiler : timer, logger, whatever {};
but independent of these conceptual details do we agree that delayed
implementation details, side effect or not, is an advantage we could
use?
> > allowing easy to
> > create and maintain yet flexible and extensible implementation. IMHO
> > two policies (one for timer and one for logging) is more than enough
> > for a profiling tool, how to collect data, when to report it how to
> > report it, what estatistical analysis should be used are all policies
> > for the logging policy, not the profiler.
>
> And how does making logging policy parameterized with components simplify
> your design?
class simple_log_policy {
public:
void begin(string x) {};
void end(string x, double, t) { cout << x << " = " << t << endl;
};
template<typename p1, typename p2, typename p3, typename p4, typename p5>
class big_and_mean_log_policy {
public:
void begin(string x) { ...do bif stuff ... };
void end(string x, double t) { ... do mean stuff... };
};
small task, small code.
big task, big code.
> > Some simple reports like
> > "foo() - 50% - 10 ms" are usually more than enough for simple tasks.
> > Let´s save the big guns for the big tasks ;)
>
> We already have boost::timer for simple tasks.
indeed, and everytime I wanto to time things I will use it,the same
way everytime I want to profile things I will use the profiler.
> I don't see how 4 policies make design more complex (IMO vice versa). And in
> any case correct design is better in long run.
when I buy a car I usually don´t want a tow-car attached to it, even
knowing that same day I might eventually need a tow-car.
the same way if a profiler needs 4 policies then 4 policies is fine,
but if single one policy deals with things that don´t regard a
profiler, this policy shoudn´t be a profiler policy.
everything above IMO
> Gennadiy
Sérgio
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk