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

RE: [boost] new version of profiling library
by Brian Braatz 12 Feb '05

12 Feb '05

I will not be able to deeply look at this til tomorrow. But my initial reaction is THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU :) > -----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 4:36 PM > To: Boost mailing list > Subject: [boost] new version of profiling library > > The profiling library has been updated in a big way. > The new files are at: > > http://www.cdiggins.com/profiler/v2/profiler.hpp > http://www.cdiggins.com/profiler/v2/profile_manager.hpp > http://www.cdiggins.com/profiler/v2/high_resolution_timer.hpp > > and as a special treat for Brian there is: > > http://www.cdiggins.com/profiler/v2/custom_profile_manager.hpp > > This last version shows one possible way of using the current library to > associate meta-data with profiles. Instead of using a multi-index > internally, I push the data into a multi-index to generate a custom > report. > I am not super happy with this version, it is more complicated than I > would > like, but it does work. > > Christopher Diggins > Object Oriented Template Library (OOTL) > http://www.ootl.org > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

new version of profiling library
by christopher diggins 12 Feb '05

12 Feb '05

The profiling library has been updated in a big way. The new files are at: http://www.cdiggins.com/profiler/v2/profiler.hpp http://www.cdiggins.com/profiler/v2/profile_manager.hpp http://www.cdiggins.com/profiler/v2/high_resolution_timer.hpp and as a special treat for Brian there is: http://www.cdiggins.com/profiler/v2/custom_profile_manager.hpp This last version shows one possible way of using the current library to associate meta-data with profiles. Instead of using a multi-index internally, I push the data into a multi-index to generate a custom report. I am not super happy with this version, it is more complicated than I would like, but it does work. Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

1 0

Proposal for an extension of the boost::signals::connection interface
by Frantz Maerten 11 Feb '05

11 Feb '05

I took a look at libsidc++ and found very interresting the way of blocking/unblocking connections. I added some small modifications in boost::signals lib in order to have this functionality (2 patches in attachment to apply at the parent of the boost_1_32_0 distrib). Only the interface of connection has changed (3 new methods), and I added a boolean flag in basic_connection struct. Also, a functor is_callable was added in the file connection.hpp, in replacement of the is_disconnected functor (used in the class slot_call_iterator). So, my questions are: 1) is it interresting/useful to incorporate it (for me, yes of course)? 2) is it a safe implementation? You can test it like that: \code void fct1(int) ; void fct2(int) ; MySignal sig ; boost::signals::connection conn = sig.connect(&fct1) ; sig(10) ; // call fct1 and fct2 conn.block() ; sig(20) ; // call only fct2 conn.unblock() ; sig(30) ; // call fct1 and fct2 \endcode --Frantz

1 0

RE: [boost] [Signals] Named slot group usage?
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 Doug Gregor > Sent: Friday, February 11, 2005 12:40 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] [Signals] Named slot group usage? > > On Feb 11, 2005, at 3:21 PM, Brian Braatz wrote: > > What about allowing the internal type to be policy\traited? > > > > i.e. I can use a vector instead of a map<> > > That gets really messy, really quick, and I only really know how to > give sane semantics for list<> and map<>. > I'm against policies except in very extreme circumstances. > > > and is it possible to allow for meta-data while you're at it? > > Worry not, we'll find a way to get meta-data into slots :) > > Doug > [Brian Braatz] (Imagine an entire football stadium standing up and cheering!) OR (just me :) )

1 0

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