-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of christopher diggins Sent: Friday, February 11, 2005 6:51 AM To: boost@lists.boost.org Subject: Re: [boost] Re: Re: Re: Re: Latest version of the profiler

----- Original Message ----- From: "Brian Braatz" <brianb@rmtg.com>

...

I might want to accumulate ALL of the calls, in one big honking

See below list.

You can already do that in a few different ways:

1) simply naming all of the profiles the same,

2) writing a new stats policy,

3) write:

{ stats_map::iterator i = default_stats_policy::stats::begin(); counted_sum cs; while (i != default_stats_policy::stats::end) { cs += *i++; } cout << "total profiler entries : " << cs.first << endl; cout << "total elapsed time : " << cs.second << endl; cout << "average time per profile : " << cs.second / cs.first <<

}

4) I could simply add some features to the default_stats_policy, if

endl; that

is more appropriate.

I don't know what the best option is.

...

Or I might want a "overview" of the average of each profile point.

Currently also already provided in the default_stats_policy, if I understand you correctly.

[Brian Braatz] YES- current implementation already gives me an average of the profile points.

...

I think we need both, in addition to allowing me to put metadata

...

the profile point. Because with the metadata, I can now go back

into through

...

the accumulated list and filter out what I care about.

I am seriously considering the metadata idea.

I agree with your earlier ideas that the identifier for a profile should not be restricted to a char*. A problem with the current design is that a by passing a type for the profile idenitifer affects not just the profile, but also the stats

[Brian Braatz] BIG GRIN :) policy

and the log policy. In this case of having three dependant policies, I would far prefer to have a single profile_management policy. This is not a huge problem however.

Thanks for your suggestions, Christopher

[Brian Braatz] Personally- I don't think having one honker policy object is the end of the world. In this case it is appropriate because the independent policies are somehow implicitly "bound" by concept. If they were not, I would argue for separate policies. Please check out the multi-index idea post earlier by me :) (that may give the flexibility, with just a little extra work, to make the profiler be "better than off the shelf". Which to me, is what Boost libraries are about :) )