November 2004 - Boost-users

Key iterators
by Chris Goller 18 Nov '04

18 Nov '04

I'm just getting into boost and I really like it. I would like to iterate over keys of a multimap. so it would look like this: std::multimap<type, type>::key_iterator i = map.beginkey(); i != map.endkey(); i++ at each i++ it would move to the next key. -or- for_each(map.beginkey(), map.endkey(), whatever); Is this possible with the boost iterators? Thanks, Chris

5 5

Re: [sigc] Re: [Boost-users] Signals & Slots
by Doug Gregor 18 Nov '04

18 Nov '04

On Nov 18, 2004, at 1:10 PM, Murray Cumming wrote: >> Very simple explanation here: my comments were about libsigc++ 1.2. > > It would be best for us to ignore them then. The differences are quite > large. Yes, please ignore them. >> I've glanced briefly at libstdc++ 2 > > For the record, Doug almost certainly means "libsigc++" instead of > "libstdc++". Correct. >> and was pleasantly surprised. I'd >> like to look into it further, but do not have the time now. I've been >> saying for a while that the Signals interface is not ready for >> standardization because we only had the one implementation (in Boost) >> and that it was not solid enough for standardization. However, with >> libstdc++ 2 adopting a similar interface, we might be able to converge >> on a single, solid interface for Signals & Slots within the C++ >> Standard Library. Library Technical Report 2 is open for submissions, >> and signals & slots have been on the wish list since the beginning... >> >> In any case, a thread titled "Boost Signals & Slots vs. libsigc++" is >> treading on dangerous territory :) > > I doubt that Boost Signals and libsigc++ 2 are significantly different. My cursory review of the libSIGc++ 2 reference documentation seems to indicate that the interfaces are similar. > A comparison should probably start by looking at the application code > needed to > 1. Create a signal > 2. Connect a slot (callback function) to a signal. > 2.2 For a member method. > 2.3 For a non-member or static function. > 3. Disconnect a slot. > 4. Bind an extra parameter, so that e.g. a slot with 4 parameters can > be > used with a signal with 3 parameters. I don't personally find the more > complex adaptors interesting. I'm not in a position to do this at the moment, although possibly in the future. It would be *wonderful* if someone went off and studied both libraries in-depth to make this comparison, especially if that person was not intimately familiar with either library beforehand. > Please do try to warn us if Boost Signals seems near to being > approved. We > would like to try porting gtkmm to it then. There is no current effort to write a proposal to bring the Boost.Signals interface to the C++ committee (that I know of). If this does happen, it will be _after_ we have a detailed comparison of both libraries and, of course, I will announce it on both the libSIGc++ and Boost mailing lists. Doug

1 0

Re: [Boost-users] Signals & Slots
by Foster, Gareth 18 Nov '04

18 Nov '04

Doug, This is what murray had to say on the GTKmm list (future correspondance, if any, to be on the libsigc++ list), it's a very pleasing response I'm sure you will agree. Perhaps you could qualify you last statement though, that one seems to have murray a little stumped. Cheers! Gaz -----Original Message----- From: Murray Cumming [mailto:murrayc@murrayc.com] Sent: 18 November 2004 09:50 To: Foster, Gareth Cc: 'gtkmm-list(a)gnome.org'; libsigc-list(a)gnome.org Subject: Re: [Boost Signals & Slots] Vs [libsigc++] Questions comparing boost::signal to libsigc++ belong on the libsigc++ mailing list. I'm CCing it. boost::signal was developer in cooperation with Karl Nelson, the main original libsigc++ developer. Also, the libsigc++ 2 API was redesigned to be as much like boost::signal as possible, so that gtkmm can easily switch to boost::signal if it becomes an API-stable dependency or it is added to the C++ Standard Library. gtkmm has a long-standing policy of not reimplementing things when we can just reuse them. This part makes no sense to me. It would have to be explained properly before we could comment: " Basically, libsigc++ is a monolithic entity covering single and multiple-target callbacks, slots, and slot binding, Signals tackles only the multiple-target callbacks, relying on other Boost libraries (especially Function and Signals) to do most of the work, so it integrates cleanly with the rest of Boost. " Murray > Hello all, > > As you will see in the forward email below, I was chatting to a bloke who > works on boost::signal, I wondered how this stacked up against libsigc++, > and whether there was any chance it could be used in GTKmm and suchlike. A > GTKmm developer did pop up on the boost list and make the valid point that > API stability would be a major issue, nevertheless, I thought I'd send > this > out, and see what people here had to say. As I said on the boost list, I > am > thinking more ... > >> "hey, what do you think to this lads" than an outright "you should be > using Boost heathens!" > > I hope such discussion isn't offtopic. > > Thanks all! > > Gaz > > > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Doug Gregor > Sent: 17 November 2004 15:49 > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Signals & Slots > > > On Nov 17, 2004, at 9:20 AM, Foster, Gareth wrote: >> I was just reading some mention of bugs in boost::signal, > > They weren't actually bugs :) > >> is this >> implementation in competition with libsigc++? i.e. does it aim to do >> the >> same job, but under a different license, or is there perhaps some >> fundamental design difference between the two? > > The Signals library aims to be much more flexible than libsigc++ and to > have an interface that is more comfortable for Boost. For instance, > slots are just function objects with similar signatures (like > Boost.Function, because Function is used in Signals), one can combine > the results of calling multiple slots into a single return value via an > arbitrary function object, and the lifetime of signals & slots is > automatically tied to "trackable" objects used in bind expressions to > build slots. > > Basically, libsigc++ is a monolithic entity covering single and > multiple-target callbacks, slots, and slot binding, Signals tackles > only the multiple-target callbacks, relying on other Boost libraries > (especially Function and Signals) to do most of the work, so it > integrates cleanly with the rest of Boost. > > Doug > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users > _______________________________________________ > gtkmm-list mailing list > gtkmm-list(a)gnome.org > http://mail.gnome.org/mailman/listinfo/gtkmm-list > Murray Cumming murrayc(a)murrayc.com www.murrayc.com www.openismus.com

4 4

Win32: Overloaded std::min and std::max
by boost＠dalvander.com 18 Nov '04

18 Nov '04

Hi all, A day ago I stumbled upon a problem using std::min and std::max when having included any boost header file on Win32 machine. The following code should not compile, according to the C++ standard: float f = 47.9999f; long l = 47L; std::max(f, l); // This should fail as the arguments aren't of the same type. But using boost (and Microsoft Visual C++ .NET 2003), it magically did. I tracked down the problem and found a 'fix' in <boost_1_31_0/boost/config/platform/win32.hpp> that looks like this: -----8<----------8<----------8<----------8<----------8<----- #ifdef BOOST_MSVC #include <algorithm> // for existing std::min and std::max namespace std{ // Apparently, something in the Microsoft libraries requires the "long" // overload, because it calls the min/max functions with arguments of // slightly different type. (If this proves to be incorrect, this // whole "BOOST_MSVC" section can be removed.) inline long min(long __a, long __b) { return __b < __a ? __b : __a; } inline long max(long __a, long __b) { return __a < __b ? __b : __a; } // The "long double" overload is required, otherwise user code calling // min/max for floating-point numbers will use the "long" overload. // (SourceForge bug #495495) inline long double min(long double __a, long double __b) { return __b < __a ? __b : __a; } inline long double max(long double __a, long double __b) { return __a < __b ? __b : __a; } } using std::min; using std::max; # endif -----8<----------8<----------8<----------8<----------8<----- I think that that block of code should be removed as it is illegal to overload any function in the standard library, according to the C++ standard, and that it also makes illegal code to compile. Cheers, Dalle

2 1

RE: [Boost-users] Signals & Slots
by Foster, Gareth 18 Nov '04

18 Nov '04

Cheers Doug, I was thinking more of a, "hey, what do you think to this lads" than an outright "you should be using Boost heathens!" :) Sound advice nontheless mate, I'll keep you posted. Gaz -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Doug Gregor Sent: 17 November 2004 20:25 To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] Signals & Slots On Nov 17, 2004, at 11:34 AM, Foster, Gareth wrote: > Thanks for the reply Doug, do you mind at all if I forward this to the > GTKmm > mailing list? Go ahead. > I would like to ask them what they think of your > implementation. I hope to use GTKmm (which uses libsigc++ of course), > and I > think boost is great, so I'd be interested to see if maybe the GTKmm > devs > could be using boost more etc. I'm sure you get the idea, main thing > is, I > don't want it to look like I am trying to start a slaging match (hence > me > asking first) :) I would suggest learning quite a bit about both libsigc++ and Boost.Signals before you try to suggest to anyone that they make such a switch, because it will surely require a significant amount of effort and may change the semantics of GTKmm considerably. Doug _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

uBlas bindings in boost 1.34
by Thomas Lemaire 18 Nov '04

18 Nov '04

dear list, looking at http://www.meta-comm.com/engineering/boost/1_32_0_draft/ it seems that uBlas bindings to LAPACK, ATLAS,... are not included in the 1.32 release, but it has been annouced on this list that they would be... Am I wrong ? What happened ? cheers, -- thomas

3 3

Dynamically growing Graphs and Graph Algorithms
by Manas Singh 18 Nov '04

18 Nov '04

The graph algorithms like depth first search and breadthe search works fine when you have the graph readily available before you call the BFS/DFS function. But I am trying to make the DFS and BFS work when I have a dynamiccaly growing graph. More specifically I start with only one node and call the DFS function. When the DFS discovers a node, I add more nodes to the graph in the visitor discover function. But I am not able to grow the graph's color map. So although I am adding vertices to the graph the color map remains the same, and so the DFS fails. Is there any way I can make DFS work with dynamically growing graphs. I come across this requirement while trying to build a web crawler using DFS. When crawling I start with one node only. But gradually I keep on adding nodes in the discover vertex method of DFS. Any suggestions are welcome. Thanks, Manas.

2 1

RE: [Boost-users] Signals & Slots
by Foster, Gareth 18 Nov '04

18 Nov '04

Interesting stuff, I had to read that a few times to understand the details :) Thanks for the reply Doug, do you mind at all if I forward this to the GTKmm mailing list? I would like to ask them what they think of your implementation. I hope to use GTKmm (which uses libsigc++ of course), and I think boost is great, so I'd be interested to see if maybe the GTKmm devs could be using boost more etc. I'm sure you get the idea, main thing is, I don't want it to look like I am trying to start a slaging match (hence me asking first) :) Cheers mate Gaz -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Doug Gregor Sent: 17 November 2004 15:49 To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] Signals & Slots On Nov 17, 2004, at 9:20 AM, Foster, Gareth wrote: > I was just reading some mention of bugs in boost::signal, They weren't actually bugs :) > is this > implementation in competition with libsigc++? i.e. does it aim to do > the > same job, but under a different license, or is there perhaps some > fundamental design difference between the two? The Signals library aims to be much more flexible than libsigc++ and to have an interface that is more comfortable for Boost. For instance, slots are just function objects with similar signatures (like Boost.Function, because Function is used in Signals), one can combine the results of calling multiple slots into a single return value via an arbitrary function object, and the lifetime of signals & slots is automatically tied to "trackable" objects used in bind expressions to build slots. Basically, libsigc++ is a monolithic entity covering single and multiple-target callbacks, slots, and slot binding, Signals tackles only the multiple-target callbacks, relying on other Boost libraries (especially Function and Signals) to do most of the work, so it integrates cleanly with the rest of Boost. Doug _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

3 3

Re: Re: posix_time::ptime constructor question
by Stuart Allie 18 Nov '04

18 Nov '04

>> Hi All, >> >> I've noticed a problem when trying to use ptime with, for example, >> STL containers and algorithms: the lack of a default constructor for >> ptime means a lot of the STL container methods just dont work. [snip] > >There is a default constructor in the 1.32 release (should be any minute now) >that constructs to not_a_date_time. You should be able to trivially patch >your current installation with this change if you don't want to upgrade. > >Jeff Thanks Jeff! I'll patch it myself until I upgrade. Just thought I should check to see if I was missing something obvious :) BTW - thanks for boost::date_time - it has become absolutely invaluable to me over recent times. Great work. Cheers, Stuart

2 1

Boost Graph Library: Property Map Conversions
by Manas Singh 17 Nov '04

17 Nov '04

Is it possible to convert other Property Maps to Vector Property Map? My requirement is that the property map should be able to grow/expand (as I am using it with a dynamic graph which also grows). But I want to make it generic so that it works for any kind of property map. So I think if I am able to convert any type of property map to vector property map then I can grow the property map, when I add new vertices to the graph. Thanks, Manas.

1 0