- Boost - lists.boost.org

Re: [boost] Unordered associative containers and swap's exceptionsafety
by JOAQUIN LOPEZ MU?Z 11 Feb '05

11 Feb '05

----- Mensaje original ----- De: Daniel James <daniel(a)calamity.org.uk> Fecha: Viernes, Febrero 11, 2005 10:45 am Asunto: [boost] Unordered associative containers and swap's exception safety > Hello everyone, > > I've got an exception safety problem implementing the hash > containers. > The draft standard says (from 6.3.1.1): > > 'For unordered associative containers, no swap function throws an > exception unless that exception is thrown by the copy constructor > or > copy assignment operator of the container's Hash or [equality] > Pred > object (if any).' > > This is a problem, because for the container to be valid, its hash > buckets, equality predicate and hash function need to consistent. > Since > both the hash and predicate can throw, this is impossible (or > hard?) to > achieve. If swapping/copying the first one succeeds, and the > second one > throws they won't match. Any ideas on what I should do? Hi Daniel. I think little can be done here without penalizing the normal users (i.e. those providing notrow Hash and Pred objects.) The solution you propose is probably the only way out, but it incurs an extra indirection each time one of the objects is accessed. FWIW, all implementations I've seen simply assume swapping of these objects won't throw --and this is the case also for other STL containers, where a simple recovery strategy would be nonetheless possible. Having a nonthrowing swap, then it is trivial to have exception-safe strong assignment. I think this has received attention at comp.std.c++, but without any definitive conclusion AFAIK. So my advice is to just assumme Hash and Pred objects won't throw when being swapped through std::swap and be happy. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[Signals] Named slot group usage?
by Douglas Gregor 11 Feb '05

11 Feb '05

I'm trying to determine how widely used named slot groups are in the Signals library. I would appreciate it if I could get some feedback on if they're used, how they're used, etc. In particular: (1) Do you use named slot groups? (2) Did the FIFO ordering guarantees in 1.32.0 and the ability to add to the front or back of the slot list alleviate the need for named slot groups? (3) If performance of connection/disconnection of named slot groups were to get worse (e.g., linear in the number of slots), would it seriously impact the performance of your application? Responses should probably come to me, personally, unless they would be of interest to the group. Background: Signals performance is sub-par, and much of the problem can be traced back to support for named slot groups. I'm trying to determine the best way to proceed. Thanks, Doug

6 7

Re: What about Multi-Index? \ RE: [boost] Latest version of theprofiler
by JOAQUIN LOPEZ MU?Z 11 Feb '05

11 Feb '05

----- Mensaje original ----- De: Brian Braatz <brianb(a)rmtg.com> Fecha: Viernes, Febrero 11, 2005 5:07 pm Asunto: What about Multi-Index? \ RE: [boost] Latest version of the profiler > (Responding to my own post again. I guess I am one of those guys who > could sit in a closet and carry on a conversation with himself) :) > > (Joaquin: ARE YOU OUT THERE?- Your thoughts appreciated) Hi Brian, here I am :) I'm afraid I haven't been following this thread close enough to emit an informed opinion. Please allow me some hours to catch up and I'll be back to you. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo > > What if instead of a map, you used Boost.MultiIndex container?. Then > exposed the configuration of that to the users of the profiler. >

1 0

[logo]
by Jonathan Turkanis 11 Feb '05

11 Feb '05

Hi, Please forgive me if this is off topic here ... Can someone recommend a free SVG editor other than Inkscape? I downloaded it yesterday and it quickly used up all the available device contexts, forcing me to shut down my system. Jonathan

2 1

RE: [boost] [Signals] Named slot group usage?
by Brian Braatz 11 Feb '05

11 Feb '05

Below: > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Doug Gregor > Sent: Friday, February 11, 2005 10:34 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] [Signals] Named slot group usage? > > > On Feb 11, 2005, at 11:49 AM, Peter Dimov wrote: > > > Doug Gregor wrote: > >> On Feb 11, 2005, at 9:51 AM, Peter Dimov wrote: > >> > >>> Douglas Gregor wrote: > >>>> Background: Signals performance is sub-par, and much of the problem > >>>> can be traced back to support for named slot groups. I'm trying to > >>>> determine the best way to proceed. > >>> > >>> Are you sure that this is the case? > >> > >> There may be other issues, but going from a std::list to a std::map > >> (as needed to efficiently support connection of named slots) hurts > >> iteration performance and increases executable code size. To counter > >> the latter problem, I've done some type erasure that slows it down > >> further and causes some of the extra heap allocations :( > > > > You mean disconnection of named slots, right? List connection is O(1), > > map - O(log N). You get ordering for free with a map, sure, but this > > is a separate issue. > > Both connection and disconnection of named slots are O(lg N), since we > need to keep the whole list ordered when named slots are present. > Connection/disconnection of unnamed slots is O(1) now. > > Iterating through a map really is slow, though... loops in operator++ > really hurt us. I've tried a few times to come up with some ultra-slick > formulation using a list for primary storage and a map indexing into > the list... but I've always failed to deal with the iterator > invalidation issues. > > > Anyway, I'm sure that few people would miss named slots. > > That's what I'm trying to figure out; but I suspect that you're right. > > > Lets' drop them. :-) > > You're not the only one to say that :) > > Doug [Brian Braatz] What about allowing the internal type to be policy\traited? i.e. I can use a vector instead of a map<> and is it possible to allow for meta-data while you're at it? Sincerely, Brian "wants the world on a silver platter" Braatz ;)

2 1

[fsm] Preliminary formal review version available
by Andreas Huber 11 Feb '05

11 Feb '05

Dear Boosters If everything goes according to plan, the fsm review will start on the 21st of February. A version that I expect to be *very* close to what will be available during the review period is available here: http://boost-sandbox.sf.net/fsm.zip The docs can also be browsed online: http://boost-sandbox.sf.net/libs/fsm This version has undergone testing on MSVC7.1 and various GCC versions. Tests on Intel are in progress. Results of tests on other compilers are very welcome. Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

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

11 Feb '05

See below > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of christopher diggins > Sent: Friday, February 11, 2005 6:51 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Re: Re: Re: Latest version of the profiler > > ----- Original Message ----- > From: "Brian Braatz" <brianb(a)rmtg.com> > > I might want to accumulate ALL of the calls, in one big honking 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 << endl; > } > > 4) I could simply add some features to the default_stats_policy, if 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 into > > the profile point. Because with the metadata, I can now go back through > > the accumulated list and filter out what I care about. > > I am seriously considering the metadata idea. > [Brian Braatz] BIG GRIN :) > 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 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 :) )

1 0

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

11 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Sérgio Vale e Pace > > On Thu, 10 Feb 2005 17:33:19 -0700, Brian Braatz <brianb(a)rmtg.com> wrote: > > Yes- those are the words I was trying to say. > > > > I might want to accumulate ALL of the calls, in one big honking list. Or > > I might want a "overview" of the average of each profile point. > > > > I think we need both, in addition to allowing me to put metadata into > > the profile point. Because with the metadata, I can now go back through > > the accumulated list and filter out what I care about. > > > > ** this is the big piece that is missing for me from off the shelf > > profilers ** > > smells like mixins to me. something like this would be apropriate (pseudo > code)? > { > profiler< log_all< log_overview<> > > prof; > // profiled code > } > > Sérgio [Brian Braatz] Hmm.. I think so. As long as there were enough methods available to me in the right fashion to allow the weave above to be able to do that. That answer would require more study. Part of the issue though, is I cannot put the metadata in, so the log_overview<> implementation might be convoluted since it is trying to double track things. Please see my next mail suggesting multi-index- I THINK that would speak to the issues I am talking about and it would give the users enough power to be able to use the profiler in MANY different ways.

1 0

What about Multi-Index? \ RE: [boost] Latest version of the profiler
by Brian Braatz 11 Feb '05

11 Feb '05

(Responding to my own post again. I guess I am one of those guys who could sit in a closet and carry on a conversation with himself) :) (Joaquin: ARE YOU OUT THERE?- Your thoughts appreciated) Was thinking about this more last night. I have NOT had deep experiences with the multi-index container from Joaquin Munez. So please excuse me if this is a bad idea. :) I am posting this as a question- What if instead of a map, you used Boost.MultiIndex container?. Then exposed the configuration of that to the users of the profiler. I propose you have a "stock, out of the box" simple version of profiler that "just works" with minimal work by the user. But also allow the user to re-configure the multi-index you are using internally. What this will buy: - The profiler now has multiple "views" - The different "ways" of looking at the data can be configured by the user - What I am storing in the profiler is also changeable via policy\traits Why do I want multiple Views? - Well in my example below, multi-index could give me all the operations that occurred with the given file - it could also give me a view that showed the average of all the calls to "savestufftofile()" - I could also JUST have a view that showed all the calls to savestufftofile() where the filename was "splat.txt" TAKING THIS FURTHER: I have not played with it, but Multi-Index supports serialization. You can now do this: * Run the test * Save the profile information * send your internal multi-index to disk * end the testing program * go make some coffee * come back later * run another program which re-serializes the data sent to file into ram again * I can now choose to report on it. Or I may have a "viewer" that I wrote specific to my application which allows me to travel through the different views of the multi-index container. SCOPE: All I am proposing is a heavily traited\ policy based implementation that uses multi-index and supports me giving it MY TYPES for id and metadata and configuring multi-index I am not proposing you write a viewer or what have you. But if you DO support this by design, I can now user your profiler class until the end of time because it does everything I could ever need until I die. (sorry for quoting all of below- it is relative to the conversation above) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Brian Braatz > Sent: Thursday, February 10, 2005 4:26 PM > To: boost(a)lists.boost.org > Subject: RE: [boost] Latest version of the profiler > > > > > -----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 :) > >

2 1

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

11 Feb '05

For me, I should be ready in a few weeks to apply the profiler to a rather large body of code and actually use it in production. HOWEVER, I need the functionality approximating what I have previously stated before I can do that. (please see the mail where I suggest Multi-Index as the internal container) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Sérgio Vale e Pace > Sent: Friday, February 11, 2005 5:48 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Re: Latest version of the profiler > > Hi, > the library evolved a lot since your first proposal, and it seens > very impressive. I agree with you about do not adding new > functionalities, in fact I would even remove some, I´m not > particularly liked the pause/resume thing, but that´s just me. I am > interested in submitting it to boost, but I have to say: I would never > be able to develop it as fast as you been doing, and I never made a > boost submission before, but I would like to give it a try. still I do > thing there is need to polish and stabilize the design a little, > gather some more use cases and document a fill "best pratices" before > trying to submitting it > > Sérgio > > On Thu, 10 Feb 2005 15:48:28 -0500, christopher diggins > <cdiggins(a)videotron.ca> wrote: > > Hey Sergio, > > > > It's nice to have a friendly and supportive voice. So what do you think > of > > the library so far? Personally I don't want to add much more > functionality > > at this time. I am however very open to helping out anyone who wants to > make > > changes and/or take over the responsibility of submitting it to boost. > Is > > this something you still might be interested in? > > > > CD > > > > > > _______________________________________________ > > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0