- Boost-users - lists.boost.org

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

trouble with large graphs
by Sebastian Weber 17 Nov '04

17 Nov '04

Hi! I am trying to use the BGL to create random graphs with 10^6 nodes and approximetly 10^12 edges. My system is: Debian Sarge with Kernel 2.6.8 on a Pentium M 1.6GHz with 1 Gig of RAM g++-3.4.2 boost 1.32.0 latest draft tarballs I am not using the STL libaries from SGI, but the standard libstdc++6 My first shot with the adjacency_list ate all my main memory. Which isn't really surprising. But adjacency_matrix failed also when I passed 10^5 nodes. Running the program within gdb gives me at least the following error message: 0x080c0fec in boost::detail::get_edge_exists<char> \\ (edge_proxy=@0x73fbdc28) at adjacency_matrix.hpp:84 84 return edge_proxy; The basic program layout is: typedef adjacency_matrix< undirectedS > graph_t; int main(int, char*[]) { // number of vertices const std::size_t vertices = int(1e5); // probability of a connection between two vertices const double pc = 0.3; // yielding number of edges to be distributed randomly const std::size_t edges = int(pc * vertices * (vertices - 1) / 2); std::size_t i = 0; while(i++ < edges) { if ((i % int(1e5)) == 0) cout << "Inserting edge no. " << i << "; completed " \\ << (double(i)/double(edges)) * 100.0 << "% ..." << endl; graph_t::edge_descriptor e; bool inserted = false; do { graph_t::vertex_descriptor a = rand_gen(), b; do { b = rand_gen(); } while (a == b); tie(e, inserted) = add_edge(a, b, g); // if insert fails, then this link already exist -> redo! } while(!inserted); } } Any help would be really appreciated. Thanks in advance! Greetings, Sebastian

3 2

Signals & Slots
by Foster, Gareth 17 Nov '04

17 Nov '04

Hello, I was just reading some mention of bugs in boost::signal, 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? Maybe it's a totally unrelated library (it doesn't look that way, but still ...). Either way, thank you for any information. Regards gaz -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Nat Goodspeed Sent: 17 November 2004 13:39 To: boost-users(a)lists.boost.org Subject: RE: [Boost-users] Signal with return value will crash > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of WangYun > Sent: Tuesday, November 16, 2004 10:03 AM > To: boost-users > Subject: [Boost-users] Signal with return value will crash > > I tried the signals, the code below will crash > > #include <boost/signal.hpp> > int _tmain(int argc, _TCHAR* argv[]) > { > boost::signal<int(int)> _sig; > _sig(10); > > return 0; > } > > but code below works well > > #include <boost/signal.hpp> > int _tmain(int argc, _TCHAR* argv[]) > { > boost::signal<void(int)> _sig; > _sig(10); > > return 0; > } > > The only difference is one has return value, the other doesn't, is this a > bug or by design? [Nat] The difference between a void slot and one with a return value is that in the latter case, the signal needs a combiner to figure out what to do with multiple returns from multiple slots. See: http://www.boost.org/doc/html/ch06s02.html#id2520177 I haven't actually tried your example, but it looks to me as though the default combiner isn't working for you. But then you probably want something other than the default anyway -- unless you don't care about the values returned by your slots -- in which case why not use void slots? _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

Dimension-independent multi_array slice creation
by Martin Magnusson 17 Nov '04

17 Nov '04

I'm having problems creating a slice of a multi_array in a dimension-independent manner. Could someone please help? The code posted here gives me the error no match for 'operator[]' in 'rn2t[indices]' Some explanations to the code snippet below: My class is templated over an unsigned int Dim. rn2t is a tensor of rank Dim+2 with real-valued elements. bin_index is of dimension Dim+1, and contains integer indices into a tensor. I want my_slice to be the one-dimensional vector pointed to by bin_index. //////////////////////////////////////////////////////////// // Convenience typedefs for multi-rank arrays: typedef typename boost::multi_array<double, Dim+2> Real_N2_Tensor; typedef boost::array<typename Real_N2_Tensor::index, Dim+2> Real_N2_Tensor_Index; typedef typename boost::multi_array<Positive, Dim+1> Positive_N1_Tensor; typedef boost::array<typename Positive_N1_Tensor::index, Dim+1> Positive_N1_Tensor_Index; //////////////////////////////////////////////////////////// template<int Dim> void My_Class<Dim>::calc( Positive_N1_Tensor_Index bin_index, bool add ) { Real_N2_Tensor rn2t; // populate rn2t... // snip... typedef typename Real_N2_Tensor::index_range Range; typename Real_N2_Tensor::index_gen indices; // Is the following lines the correct way to populate 'indices'? indices[bin_index[0]]; for (int a = 0; a < Dim; ++a) indices[bin_index[a+1]]; indices[Range()]; typename Real_N2_Tensor::array_view<1>::type my_slice = rn2t[indices]; ///// ERROR HERE // snip... } //////////////////////////////////////////////////////////// / martin

1 0

Re: Re: [Boost-users] Re: Re: Signal with return value will crash
by WangYun 17 Nov '04

17 Nov '04

>On Nov 16, 2004, at 10:48 PM, a_hao(a)21cn.com wrote: >> I'm using win2000 pro build 5.00.2195 service pack4, Visual Studio >> 2003 version 7.1.3091, boost v1_31_0. >> And I also tested this using boost v1_32_0, also has this bug. >> >> Before crash, this assert will fail: "Assertion failed: first != last, >> file d:\boost_1_31_0\boost\last_value.hpp, line 23" > >Oh, right! That is by-design, then: when you declare a non-void signal >with the default combiner, it has to get a value from somewhere to >return. When first == last, there is no such value so it asserts. If >you don't want this behavior, you can write your own combiner that gets >a result from somewhere else. > > Doug > Ok, I see, thanks Doug and Nat.

1 0

Re: RE: [Boost-users] Signal with return value will crash
by WangYun 17 Nov '04

17 Nov '04

> >[Nat] The difference between a void slot and one with a return value is >that in the latter case, the signal needs a combiner to figure out what >to do with multiple returns from multiple slots. See: > >http://www.boost.org/doc/html/ch06s02.html#id2520177 > >I haven't actually tried your example, but it looks to me as though the >default combiner isn't working for you. But then you probably want >something other than the default anyway -- unless you don't care about >the values returned by your slots -- in which case why not use void >slots? > But I think the signal doesn't care about whether or not there is any slot connected to it, it just fire the signal and handle the return value if there is any. Why it will crash when there is no slot connected to it. Wang Yun

1 0

Re: Re: Signal with return value will crash
by a_hao＠21cn.com 17 Nov '04

17 Nov '04

>> Hi, >> >> I tried the signals, the code below will crash >> >> #include <boost/signal.hpp> >> int _tmain(int argc, _TCHAR* argv[]) >> { >> boost::signal<int(int)> _sig; >> _sig(10); >> >> return 0; >> } >> >> but code below works well >> >> #include <boost/signal.hpp> >> int _tmain(int argc, _TCHAR* argv[]) >> { >> boost::signal<void(int)> _sig; >> _sig(10); >> >> return 0; >> } >> >> The only difference is one has return value, the other doesn't, is >> this a bug or by design? > >Sounds like a bug... could you give us more information? Compiler, >platform, Boost version, etc. > > Doug > I'm using win2000 pro build 5.00.2195 service pack4, Visual Studio 2003 version 7.1.3091, boost v1_31_0. And I also tested this using boost v1_32_0, also has this bug. Before crash, this assert will fail: "Assertion failed: first != last, file d:\boost_1_31_0\boost\last_value.hpp, line 23" Thanks, Wang Yun

3 2

greg_facet max() macro warning
by Timothy Ritchey 17 Nov '04

17 Nov '04

I have a fresh install of the 1.32 draft release tarball compiled with the intel-win32 environment (I have Intel's C++ version 8.1 installed). I started getting the following warning when I uprgaded the draft tarballs (I'm using intel's 8.1 compiler in Visual Studio .NET): C:\Projects\base\boost\boost/date_time/gregorian/greg_facet.hpp(293): warning #54: too few arguments in macro invocation greg_month::max(), s); I seem to be getting them with both greg_month::max() and greg_weekday::max() I noticed that there appeared to be some kind of guards in constrained_value.hpp (BOOST_PREVENT_MACRO_SUBSTITUTION) that were added in 1.32 compared to my 1.31 install. Any advice on what I could be doing wrong? Cheers, tim

3 3