February 2005 - Boost - lists.preview.boost.org

RE: [boost] Latest version of the profiler
by Brian Braatz 11 Feb '05

11 Feb '05

> -----Original Message----- [Brian Braatz] Wrote: > > I for example- MIGHT take your library and stuff __FILE__ __LINE__ into > > the id. For this I would use a macro. This is also why I made the > > request for the char*name type to be a template param. I may want to > > plop in my own struct that has the __FILE__ and __LINE__ in it. > > The current implementation uses a map<string, pair<int, double> > for > gathering of stats. This makes it easy to access data by profile name and > to > accumulate data for a named profile. Of course this could be rewritten, > but > my goal is to do as little work as possible. ;) > Christopher Diggins Wrote: > What if instead you wrote: > > #define PROFILE(TKN) BOOST_PROFILE(#TKN##__FILE__##__LINE__) > > Or better yet: > > #ifndef BOOST_PROFILING_OFF > map<string, pair<int, string> > my_map; > #endif > > #ifndef BOOST_PROFILING_OFF > #define PROFILE(TKN) mymap[#TKN] = pair<int,string>(__LINE__, __FILE__); > BOOST_PROFILE(#TKN); > #else > #define PROFILE(TKN) /* */ > #endif > > Would these be acceptable alternatives? > [Brian Braatz] I spent a little more time (that I really don't have today but the boost mailing list "Draws me in..." :) ) Looking at your code at: http://www.cdiggins.com/profiler/profiler.hpp One thing that AT FIRST looked problematic for my usage is this: typedef map<string, counted_sum> stats_map; .... struct default_stats_policy { static stats_map stats; ... But, then I realized this is in a default Policy. So I can change that (cool). I need to track on a per-thread basis each thread's profile information. Hmm... On the metadata issue, things I need to track __FILE__ I have the following needs: 1- I have some code that is using wstring for everything else. So the std::string seems weird here (yes I know boost is not completely wstring compatible). 2- I need to store BOTH the "average" for that area of code, and also track the history of all the calls. I.e. look at the profile for the last time we were in that function 2- I need to be able to plug a structure of my metadata in there somewhere. - This will allow me to after the fact, scan the map and find "sets" of profile information based on my specific stuff. Examples: Stuff threadID in there, so "later" I can filter out just the stuff for that thread. At runtime, set a particular flag on the metadata based on a business condition in the code. What I would like to see in the profiler: * An ability to give it something other than std::string for the KEY type of the map * An ability to track these readings in a list with my metadata Examples: Struct ProfileDataFileOperations { string sId; std::string sFILE; int iLine; string sfiletouched; MyProfileData(string id, string file, int line,string sFileYouTouched) : sId(id), sFILE(file), iLine(line), sfiletouched(sFileYouTouched) {} Bool operator==( ProfileDataFileOperations const & other) { return sId == other.sId; } } void savestufftofile(std::string sfile) { FileOpProfiler p(ProfileDataFileOperations("savestufftofile",__FILE__,__LINE__, sFile)); } I would like to then, go back and generate a report on ALL operations that touched a specific file. I would also like to go back and see all the things that touched savestufftofile I might also want to go back and filter out based upon some other combination of data. The things I am describing fall into my basic issue with using profilers. They gave you MORE information than you need, without an easily ability to filter out or cross cut the information. So the implementation of what I am suggesting is this: * Make the TYPE in the map be a typedef in the policy (the template could default to std::string) * allow me to provide my OWN way of storing the information For above, I might want to keep a big old list Or maybe I want what you have, but I want to plug a list<> into the element you are using to track the profile information for a "thing". I am sorry if it feels like I am blowing the scope of what you are trying to do out of the water. I do think with some tweaks, though, you could have a profiler class that could stand up to most of not all of the "weird" desires of folks like me :)

1 0

[mpl] vector_c with enumerators?
by Larry Evans 11 Feb '05

11 Feb '05

Is the following supposed to compile: enum visitor_numerals { visitor_n0 , visitor_n1 }; typedef mpl::vector_c<visitor_numerals,visitor_n0> vec_viz_type; typedef mpl::at_c<vec_viz_type,0>::type vec_viz0_type; it does with intel but with gcc, I get: bjam --v2 toolset=gcc vector_enum_test ...patience... ...found 751 targets... ...updating 4 targets... gcc.compile.c++ ../../../../bin.v2/lje/libs/fields_visitor/test/vector_enum_test.test/gcc/debug/vector_enum_test.o /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/aux_/preprocessed/gcc/vector_c.hpp: In instantiation of `boost::mpl::vector_c<visitor_numerals, 0l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l>': /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/aux_/has_tag.hpp:20: instantiated from `boost::mpl::aux::has_tag<test()::vec_viz_type, mpl_::bool_< false> >' /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/sequence_tag.hpp:115: instantiated from `boost::mpl::sequence_tag<test()::vec_viz_type>' /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/at.hpp:45: instantiated from `boost::mpl::at_c<test()::vec_viz_type, 0l>' vector_enum_test.cpp:11: instantiated from here /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/aux_/preprocessed/gcc/vector_c.hpp:47: error: invalid conversion from `long int' to `visitor_numerals'

3 8

thread_group.count()?
by Preston A. Elder 10 Feb '05

10 Feb '05

Is there any fantastically good reason why there is no way of getting a count of how many threads are being handled by a thread_group? I want to set up a worker thread pool, a new thread is added as the queue size goes up, and it removed itself if the queue size is not enough to warrant it. This mechanism, however, is complicated muchly when thread_group doesn't have a way for me to determine how many threads I currently have, in an effort to ensure the ending the thread will cause it to go below the minimum, or spawning a new one go above the maximum. Obviously, I could write my own thread_group, but I can think of no reason for boost's thread_group to not have a count() method. -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)

3 3

Boost Profiler Proposal
by christopher diggins 10 Feb '05

10 Feb '05

I have updated the Profiler (and done some testing using Visual C++, 7.1) at http://www.cdiggins.com/profiler/ . I have mostly decided to freeze the features for the profiler mini-library as described and posted at http://www.cdiggins.com/profiler/ . My question to the group is: would you use this library as it is? If you don't want to mail the group, I would appreciate even just a quick note: yes, no, maybe. If anyone has a POSIX high-resolution timer modeled on the Boost.Timer concept to share, it would be greatly appreciated! I would also appreciate new profiling policies, to include as examples. PS: this profiling tool seems to be a natural fit for the Boost.Test macros like BOOST_CHECK_NO_THROW, I currently use something like: BOOST_PROFILE_AND_CHECK_NO_THROW(TKN) BOOST_CHECK_NO_THROW(BOOST_PROFILE(TKN)) Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

6 16

RE: [boost] Latest version of the profiler
by Brian Braatz 10 Feb '05

10 Feb '05

> -----Original Message----- > Subject: [boost] Latest version of the profiler > > I have updated the profiler library to take into account many of the > excellent suggestions. I have tried to give acknowledgements where it is > due, please let me know if I have overlooked anyone. > > The latest version is at: http://www.cdiggins.com/profiler > > The major changes are: > - defining BOOST_PROFILING_OFF causes all member calls to become empty > statements > - basic_profiler now has three policies: logging, stats, timer > - profiler now supports: restart, stop, pause, resume, generate_report > - fixed QueryPerformanceCounter() api bug in HighResolutionTimer > [Brian Braatz] Hahahahaha " Macros were avoided because everyone knows macros are evil, unless we are the ones writing them." I LOVE THIS LINE. Please keep it in :) On a serious note though, with your lib done the way it is , if someone WANTS macros, there is nothing preventing them from having them. I for example- MIGHT take your library and stuff __FILE__ __LINE__ into the id. For this I would use a macro. This is also why I made the request for the char*name type to be a template param. I may want to plop in my own struct that has the __FILE__ and __LINE__ in it.

2 1

RE: [boost] Latest version of the profiler
by Brian Braatz 10 Feb '05

10 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of christopher diggins > > I have updated the profiler library to take into account many of the > excellent suggestions. I have tried to give acknowledgements where it is > due, please let me know if I have overlooked anyone. > > The latest version is at: http://www.cdiggins.com/profiler > > The major changes are: > - defining BOOST_PROFILING_OFF causes all member calls to become empty > statements > - basic_profiler now has three policies: logging, stats, timer > - profiler now supports: restart, stop, pause, resume, generate_report > - fixed QueryPerformanceCounter() api bug in HighResolutionTimer > > If you have brought an issue up previously (or think of a new one) which > you > feel is a significant omission of this library and would affect whether or > not you could use it, please feel free to bring it up again. > > I am still looking for a posix high-resolution timer. Hartmut suggested a > couple of Posix timers which he got off of Google, which unfortunately > were > unusable: one was GPL'ed and the other lacked source code. Gennadiy said > there were some on the mailing list (I couldn't find ), and that he uses > one > in the CVS but I don't know how to use the CVS. I also can not test Posix > timers, since I only use visual C++. I believe that perhaps > boost::date_time > contains a good resolution timer, but I can't tell. > [Brian Braatz] Christopher, I really like the way this is shaping up. I encourage you onward :) I am in the thick of some deep work things right now and will not be able to really play with this for a week or two, but by reading the docs it looks like it would be very usable for the types of problems I have with profiling. Suggestion \ Comments: A suggestion would be to make the TYPE for the name be a template param. (or maybe a typedef in the policy). For my needs, I need to store a structure in this place and not just a string. This goes back to the meta-data discussion awhile back. I believe the users of the library need to be able to give you the type to store for the id, this way I can use whatever ID concept I need to, and it means I can store extra metadata in that (without having to look it up in a separate map<> or something)

1 0

Re: boost::rtl / rel where can I get some more infos
by Vinzenz Feenstra 10 Feb '05

10 Feb '05

What do you think, how long it would take that rtl would be released with boost? ( I know I am asking too much but this would be the last question) BR and Many thanks Vinzenz

1 0

function_traits
by Joel de Guzman 10 Feb '05

10 Feb '05

Hi, I find the interface: function_traits<F>::arity function_traits<F>::result_type function_traits<F>::argN_type (especially the last) awkward in TMP code. In the interest of not having metafunction blobs, I'd suggest the interface: function_arity<F>::value function_result<F>::type function_arg_c<N, F>::type function_arg<mpl::int_<N>, F>::type In particular, I need the function_arg(_c) metafunctions. It is very awkward to get the Nth function argument, given a constant N. Thoughts? Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

4 6

Release 1.33
by Robert Ramey 10 Feb '05

10 Feb '05

I would hope that soon we might think of releasing an updated version of boost - 1.33 As far as I know this might include a)bug fixes for herefore untested combinations of compilers, varients, etc b)Jonathon Turkanis stream bufffer library c)Other libraries (Ranges?) d)Serialization library - bugfixes and DLL version Robert Ramey

6 15

RE: [boost] Wave C++ Review Begins Today - February 7, 2005
by Michiel Salters 10 Feb '05

10 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Doug Gregor > Sent: woensdag 9 februari 2005 17:23 > To: boost(a)lists.boost.org > Subject: Re: [boost] Wave C++ Review Begins Today - February 7, 2005 > ... > Even dereferencing *last could be a bug, if it is > past-the-end. For iterators referencing contiguous memory > (vectors and pointers only, as you've said), one would need to write > > scanner.last = scanner.first + std::distance(first, last); True, but that's an partial fix. For now, I've fixed that bug too in my vector<char> wrapper but it's becoming complex. I'm afraid someone will have to write re2cpp. > > I really have to say Dinkumware did a fine job here, this > would have > > been very hard to find without these checks. > > FWIW, STLport and newer versions of GCC (Apple GCC 3.3, FSF > GCC 3.4) have similar debugging modes. They've been > invaluable in rooting out subtle bugs like those that stem > from iterator invalidation. Yep, although I'm currently wondering if they're 100% right. Is it legal to compare iterators from different containers? I can't find the appropriate wording so I'll just trust Dinkumware here. My current problem is, somewhere deep down in cpp_macromap.hpp a simple innocent if (first != last) statement (line 433) triggers another assertion. These are iterator_facade's (which I don't grok) and end up comparing iterators to two distinct containers. Looking the other way on the callstack, I see some deeply suspect iterators (singular, destroyed, ?) Too messy to say what happened. Regards, Michiel Salters This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

6 7