- Boost-users - lists.preview.boost.org

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

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

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

17 Nov '04

> -----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?

1 0

posix_time::ptime constructor question
by Stuart Allie 17 Nov '04

17 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. For example: std::vector<ptime> v; v.resize(10); // fails because there is no ptime::ptime() constructor! So, my questions are: 1. Is there an easy way to work around this? 2. What's the reason for the lack of a default c'tor? (Couldn't it just set the object to not_a_date_time?) 3. Am I missing something obvious and in fact the ptime class is perfectly compatible with the STL? Thanks, Stuart Allie

2 1

RE: [Boost-users] RE: Manual in pdf?
by Foster, Gareth 17 Nov '04

17 Nov '04

I suppose I'd better shut up and go and read up on Boostbook then :) I presume all Boost projects will be using this in the future, nice consistent docs, loverly! Gaz -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Vladimir Prus Sent: 17 November 2004 12:37 To: boost-users(a)lists.boost.org Subject: [Boost-users] RE: Manual in pdf? Foster, Gareth wrote: > You can make PDF documents in openoffice.org writer</shameless > free-software plug> > > No, seriously, OO.o can import HTML, so you could save the pages locally, > import them into one big OO.o doc (ironic short-hand for document), and > then save that out as PDF, then share it of course so that nobody else has > to spend 20 mins doing it. I'm afraid it's a bit too early for shameless free-software plug :-( OO.o can't generate bookmarks or hyperlinks in PDF, which takes away one half of PDF coolness. Boostbook does it all. - Volodya _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

RE: [Boost-users] Manual in pdf?
by Foster, Gareth 17 Nov '04

17 Nov '04

You can make PDF documents in openoffice.org writer</shameless free-software plug> No, seriously, OO.o can import HTML, so you could save the pages locally, import them into one big OO.o doc (ironic short-hand for document), and then save that out as PDF, then share it of course so that nobody else has to spend 20 mins doing it. Are there plans to get all of the boost projects using something like Doxygen? I think that can spit out more file formats than you could ever want. Gaz -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Daniel Lidström Sent: 17 November 2004 07:35 To: 'boost-users(a)lists.boost.org' Subject: SV: [Boost-users] Manual in pdf? ) ) Daniel Lidström writes: ) > Hi, ) > ) > is the manual available in pdf or postscript? Or is there a way ) > to print it? The online manual is not very printer-friendly. ) ) Daniel, ) ) I assume you are talking about Boost-wide PDF (some of the Boost ) libraries/tools provide a standalone one on their own). In that case, ) it's not available for 1.31; we are working on making it available in ) the upcoming 1.32.0, which is due in a couple of days. ) How about the Spirit manual? Will it be available in printable format with 1.32.0? Thanks! -- Daniel _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

3 2

Signal with return value will crash
by WangYun 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? Thanks, Wang Yun

2 1

RE: [Boost-users] Re: Problems with boost::variant
by Simmons, Aaron 16 Nov '04

16 Nov '04

> I'm pretty sure that's an MPL limitation. If you > want to build a vector of more than 10 elements, > you need to > > #include <boost/mpl/vector20.hpp> > > or if you need more than 20 elements, > > #include <boost/mpl/vector30.hpp> I've noticed that the vectorXX.hpp files only allow you to make a vector with exactly that many items. What do you do if you want a vector of, say, 25 items?

2 1

Manual in pdf?
by Daniel Lidström 16 Nov '04

16 Nov '04

Hi, is the manual available in pdf or postscript? Or is there a way to print it? The online manual is not very printer-friendly. -- Daniel

2 1

help getting started with boost::graph
by Andrew Chapman 16 Nov '04

16 Nov '04

Hi everyone, I've got a fairly simple use for boost::graph, and I've been trying to get it working, but the documentation, whilst thorough, isn't being too helpful in getting me started. What I'm trying to do, is build a graph of polygon mesh edges, which are simply pairs of unsigned ints. I need to find contiguous edge lists. Here's the setup code: // setup graph typedef std::pair<int, int> Edge; typedef adjacency_list<vecS, vecS, undirectedS> Graph; Graph g; // add an edge add_edge(6,7, g); cout << "Total number of vertices: " << num_vertices(g) << endl; Which then outputs that I have 8 vertices in my graph (0 through 7), instead of just the one I've added. So, it appears that the vertex list is automatically managed to be contiguous. Should I instead be adding all my edges, not caring about their vertex index, and adding a per-vertex property to keep track of their associated polygon mesh vertex numbers? If so, then I presume my code for adding the edges becomes something like (only psuedo-code here): vertex_descriptor v1 = add_vertex(g); vertex_descriptor v2 = add_vertex(g); set_property(v1, MyIndexProperty, 6); set_property(v2, MyIndexProperty, 7); add_edge(v1,v2,g); ..instead of what I had: add_edge(6,7, g); Does that sound right? In that case, is there a quick way of locating vertex_descriptor in a graph based on a vertex property? Something like: find_vertex(g, MyIndexProperty, 6); Sorry for all the lack of understanding, but it is quite a simple thing I'm wanting to use the library for, and I'm finding the documentation quite overwhelming. I suppose it is intended for when you're using the graphs in a much more complex scenario. Thanks in advance for any tips. AC.

2 1

Problems with boost::variant
by Alex Drummond 16 Nov '04

16 Nov '04

Hi, I'm using boost 1.31.0 and I'm having some trouble using type sequences with boost::variant. There seems to be an arbitrary limit on their length. For example, the following code compiles: [---------------------------------------- #include <boost/variant.hpp> #include <boost/mpl/vector.hpp> typedef boost::mpl::vector< boost::recursive_wrapper<struct A> > T0; typedef boost::mpl::push_front<T0, boost::recursive_wrapper<struct B> >::type T1; typedef boost::mpl::push_front<T1, boost::recursive_wrapper<struct C> >::type T2; typedef boost::mpl::push_front<T2, boost::recursive_wrapper<struct D> >::type T3; typedef boost::mpl::push_front<T3, boost::recursive_wrapper<struct E> >::type T4; typedef boost::mpl::push_front<T4, boost::recursive_wrapper<struct F> >::type T5; typedef boost::mpl::push_front<T5, boost::recursive_wrapper<struct G> >::type T6; typedef boost::mpl::push_front<T6, boost::recursive_wrapper<struct H> >::type T7; typedef boost::mpl::push_front<T7, boost::recursive_wrapper<struct I> >::type T8; typedef boost::make_variant_over<T8>::type Var; struct A { Var v; }; struct B { Var v; }; struct C { Var v; }; struct D { Var v; }; struct E { Var v; }; struct F { Var v; }; struct G { Var v; }; struct H { Var v; }; struct I { Var v; }; int main() { return 0; } ----------------------------------------] But with the addition of one more type to the sequence: [---------------------------------------- typedef boost::mpl::push_front<T8, boost::recursive_wrapper<struct J> >::type T9; ...... struct J { Var v; } ----------------------------------------] And an appropriate redefinition of Var: typedef boost::make_variant_over<T9>::type Var; gcc 3.3.3 gives various obscure template error messages: /usr/include/boost/mpl/apply_if.hpp: In instantiation of `boost::mpl::push_front<boost::mpl::vector10<boost::recursive_wrapper<J>, boost::recursive_wrapper, boost::recursive_wrapper<H>, boost::recursive_wrapper<G>, boost::recursive_wrapper<F>, boost::recursive_wrapper<E>, boost::recursive_wrapper<D>, boost::recursive_wrapper<C>, boost::recursive_wrapper, boost::recursive_wrapper<A> >, boost::detail::variant::backup_holder<void*> >': /usr/include/boost/mpl/apply_if.hpp:39: instantiated from `boost::mpl::apply_if<boost::variant<boost::detail::variant::over_sequence<T9>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::has_fallback_type_, boost::mpl::identity<T9>, boost::mpl::push_front<boost::mpl::vector10<boost::recursive_wrapper<J>, boost::recursive_wrapper, boost::recursive_wrapper<H>, boost::recursive_wrapper<G>, boost::recursive_wrapper<F>, boost::recursive_wrapper<E>, boost::recursive_wrapper<D>, boost::recursive_wrapper<C>, boost::recursive_wrapper, boost::recursive_wrapper<A> >, boost::detail::variant::backup_holder<void*> > >' /usr/include/boost/variant/variant.hpp:226: instantiated from `boost::detail::variant::make_storage<boost::mpl::vector10<boost::recursive_wrapper<J>, boost::recursive_wrapper, boost::recursive_wrapper<H>, boost::recursive_wrapper<G>, boost::recursive_wrapper<F>, boost::recursive_wrapper<E>, boost::recursive_wrapper<D>, boost::recursive_wrapper<C>, boost::recursive_wrapper, boost::recursive_wrapper<A> >, boost::variant<boost::detail::variant::over_sequence<T9>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::has_fallback_type_>' /usr/include/boost/variant/variant.hpp:1079: instantiated from `boost::variant<boost::detail::variant::over_sequence<T9>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>' test.cc:19: instantiated from here /usr/include/boost/mpl/apply_if.hpp:39: error: base class ` boost::mpl::push_front_traits<boost::mpl::aux::vector_tag<10> >::algorithm<boost::mpl::vector10<boost::recursive_wrapper<J>, boost::recursive_wrapper, boost::recursive_wrapper<H>, boost::recursive_wrapper<G>, boost::recursive_wrapper<F>, boost::recursive_wrapper<E>, boost::recursive_wrapper<D>, boost::recursive_wrapper<C>, boost::recursive_wrapper, boost::recursive_wrapper<A> >, boost::detail::variant::backup_holder<void*> >' has incomplete type /usr/include/boost/mpl/apply_if.hpp: In instantiation of `boost::mpl::apply_if<boost::variant<boost::detail::variant::over_sequence<T9>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::has_fallback_type_, boost::mpl::identity<T9>, boost::mpl::push_front<boost::mpl::vector10<boost::recursive_wrapper<J>, boost::recursive_wrapper, boost::recursive_wrapper<H>, boost::recursive_wrapper<G>, boost::recursive_wrapper<F>, boost::recursive_wrapper<E>, boost::recursive_wrapper<D>, boost::recursive_wrapper<C>, boost::recursive_wrapper, boost::recursive_wrapper<A> >, boost::detail::variant::backup_holder<void*> > >': /usr/include/boost/variant/variant.hpp:226: instantiated from `boost::detail::variant::make_storage<boost::mpl::vector10<boost::recursive_wrapper<J>, boost::recursive_wrapper, boost::recursive_wrapper<H>, boost::recursive_wrapper<G>, boost::recursive_wrapper<F>, boost::recursive_wrapper<E>, boost::recursive_wrapper<D>, boost::recursive_wrapper<C>, boost::recursive_wrapper, boost::recursive_wrapper<A> >, boost::variant<boost::detail::variant::over_sequence<T9>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::has_fallback_type_>' /usr/include/boost/variant/variant.hpp:1079: instantiated from `boost::variant<boost::detail::variant::over_sequence<T9>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>' test.cc:19: instantiated from here /usr/include/boost/mpl/apply_if.hpp:39: error: no type named `type' in `struct boost::mpl::push_front<boost::mpl::vector10<boost::recursive_wrapper<J>, boost::recursive_wrapper, boost::recursive_wrapper<H>, boost::recursive_wrapper<G>, boost::recursive_wrapper<F>, boost::recursive_wrapper<E>, boost::recursive_wrapper<D>, boost::recursive_wrapper<C>, boost::recursive_wrapper, boost::recursive_wrapper<A> >, boost::detail::variant::backup_holder<void*> >' /usr/include/boost/variant/variant.hpp: In instantiation of `boost::detail::variant::make_storage<boost::mpl::vector10<boost::recursive_wrapper<J>, boost::recursive_wrapper, boost::recursive_wrapper<H>, boost::recursive_wrapper<G>, boost::recursive_wrapper<F>, boost::recursive_wrapper<E>, boost::recursive_wrapper<D>, boost::recursive_wrapper<C>, boost::recursive_wrapper, boost::recursive_wrapper<A> >, boost::variant<boost::detail::variant::over_sequence<T9>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::has_fallback_type_>': /usr/include/boost/variant/variant.hpp:1079: instantiated from `boost::variant<boost::detail::variant::over_sequence<T9>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>' test.cc:19: instantiated from here /usr/include/boost/variant/variant.hpp:226: error: no type named `type' in ` struct boost::mpl::apply_if<boost::variant<boost::detail::variant::over_sequence<T9>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::has_fallback_type_, boost::mpl::identity<T9>, boost::mpl::push_front<boost::mpl::vector10<boost::recursive_wrapper<J>, boost::recursive_wrapper, boost::recursive_wrapper<H>, boost::recursive_wrapper<G>, boost::recursive_wrapper<F>, boost::recursive_wrapper<E>, boost::recursive_wrapper<D>, boost::recursive_wrapper<C>, boost::recursive_wrapper, boost::recursive_wrapper<A> >, boost::detail::variant::backup_holder<void*> > >' /usr/include/boost/variant/variant.hpp:230: error: no type named `type' in ` struct boost::mpl::apply_if<boost::variant<boost::detail::variant::over_sequence<T9>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::has_fallback_type_, boost::mpl::identity<T9>, boost::mpl::push_front<boost::mpl::vector10<boost::recursive_wrapper<J>, boost::recursive_wrapper, boost::recursive_wrapper<H>, boost::recursive_wrapper<G>, boost::recursive_wrapper<F>, boost::recursive_wrapper<E>, boost::recursive_wrapper<D>, boost::recursive_wrapper<C>, boost::recursive_wrapper, boost::recursive_wrapper<A> >, boost::detail::variant::backup_holder<void*> > >' /usr/include/boost/variant/variant.hpp:236: error: no type named `type' in ` struct boost::mpl::apply_if<boost::variant<boost::detail::variant::over_sequence<T9>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::has_fallback_type_, boost::mpl::identity<T9>, boost::mpl::push_front<boost::mpl::vector10<boost::recursive_wrapper<J>, boost::recursive_wrapper, boost::recursive_wrapper<H>, boost::recursive_wrapper<G>, boost::recursive_wrapper<F>, boost::recursive_wrapper<E>, boost::recursive_wrapper<D>, boost::recursive_wrapper<C>, boost::recursive_wrapper, boost::recursive_wrapper<A> >, boost::detail::variant::backup_holder<void*> > >' /usr/include/boost/variant/variant.hpp:252: error: no type named `type' in ` struct boost::mpl::apply_if<boost::variant<boost::detail::variant::over_sequence<T9>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::has_fallback_type_, boost::mpl::identity<T9>, boost::mpl::push_front<boost::mpl::vector10<boost::recursive_wrapper<J>, boost::recursive_wrapper, boost::recursive_wrapper<H>, boost::recursive_wrapper<G>, boost::recursive_wrapper<F>, boost::recursive_wrapper<E>, boost::recursive_wrapper<D>, boost::recursive_wrapper<C>, boost::recursive_wrapper, boost::recursive_wrapper<A> >, boost::detail::variant::backup_holder<void*> > >' /usr/include/boost/variant/variant.hpp: In instantiation of `boost::variant<boost::detail::variant::over_sequence<T9>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>': test.cc:19: instantiated from here /usr/include/boost/variant/variant.hpp:1079: error: no type named `type' in ` struct boost::detail::variant::make_storage<boost::mpl::vector10<boost::recursive_wrapper<J>, boost::recursive_wrapper, boost::recursive_wrapper<H>, boost::recursive_wrapper<G>, boost::recursive_wrapper<F>, boost::recursive_wrapper<E>, boost::recursive_wrapper<D>, boost::recursive_wrapper<C>, boost::recursive_wrapper, boost::recursive_wrapper<A> >, boost::variant<boost::detail::variant::over_sequence<T9>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::has_fallback_type_>' /usr/include/boost/variant/variant.hpp:1118: error: no type named `type' in ` struct boost::detail::variant::make_storage<boost::mpl::vector10<boost::recursive_wrapper<J>, boost::recursive_wrapper, boost::recursive_wrapper<H>, boost::recursive_wrapper<G>, boost::recursive_wrapper<F>, boost::recursive_wrapper<E>, boost::recursive_wrapper<D>, boost::recursive_wrapper<C>, boost::recursive_wrapper, boost::recursive_wrapper<A> >, boost::variant<boost::detail::variant::over_sequence<T9>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::has_fallback_type_>' I'd be grateful for any help... Thanks Alex -- "What possible harm could one insane mutant tentacle do?"

2 2

bind forwarding problem
by Trent Hill 16 Nov '04

16 Nov '04

Hi all, I'm running into a compile error using bind with visual c++ 7.1 and am hoping some clever cookie here will be able to help. I've whittled the issue down to a few simple functions (you'll have to trust that it makes sense in the original context): template <typename T_Param> void foo(T_Param a_param) { } template <typename T_Param> void callFooWith(T_Param a_param) { boost::bind(&foo<T_Param>, a_param)(); // <- (1) ERROR HERE } void bar(int) { } int main(int a_argc, char *a_argv[]) { callFooWith(42); // <- (2) FINE callFooWith(boost::bind(&bar, 10)); // <- (3) FAILS return 0; } If I remove line (3), it compiles without error. Adding line (3) results in a compile error reported at line (1) (error is at bottom of post). The compile error seems to stem from operator() on line (1); if the "()" is removed from line (1), the code will compile without error. Any ideas? Thanks a bunch, Trent. *** Error message follows *** c:/workspace\swlib2\BOOST\1.30.2\win32\files\boost\bind.hpp(186) : error C2664: 'void (T_Param)' : cannot convert parameter 1 from 'boost::_bi::result_traits<R,F>::type' to 'boost::_bi::bind_t<R,F,L>' with [ T_Param=boost::_bi::bind_t<void,void (__cdecl *)(int),boost::_bi::list1<boost::_bi::list_av_1<int>::B1>> ] and [ R=void, F=void (__cdecl *)(int) ] and [ R=void, F=void (__cdecl *)(int), L=boost::_bi::list1<boost::_bi::list_av_1<int>::B1> ] Expressions of type void cannot be converted to other types c:/workspace\swlib2\BOOST\1.30.2\win32\files\boost\bind\bind_template.hpp(21) : see reference to function template instantiation 'R boost::_bi::list1<A1>::operator ()<boost::_bi::bind_t<R,F,L>::result_type,void(__cdecl *)(T_Param),boost::_bi::list0>(boost::_bi::type<T>,void,A &) const' being compiled with [ R=boost::_bi::bind_t<void,void (__cdecl *)(int),boost::_bi::list1<boost::_bi::list_av_1<int>::B1>>::result_type, A1=boost::_bi::list_av_1<boost::_bi::bind_t<void,void (__cdecl *)(int),boost::_bi::list1<boost::_bi::list_av_1<int>::B1>>>::B1, F=void (__cdecl *)(int), L=boost::_bi::list1<boost::_bi::list_av_1<int>::B1>, T_Param=boost::_bi::bind_t<void,void (__cdecl *)(int),boost::_bi::list1<boost::_bi::list_av_1<int>::B1>>, T=boost::_bi::bind_t<void,void (__cdecl *)(int),boost::_bi::list1<boost::_bi::list_av_1<int>::B1>>::result_type, A=boost::_bi::list0 ] c:/workspace\swlib2\BOOST\1.30.2\win32\files\boost\bind\bind_template.hpp(19) : while compiling class-template member function 'boost::_bi::bind_t<R,F,L>::result_type boost::_bi::bind_t<R,F,L>::operator ()(void)' with [ R=void, F=void (__cdecl *)(boost::_bi::bind_t<void,void (__cdecl *)(int),boost::_bi::list1<boost::_bi::list_av_1<int>::B1>>), L=boost::_bi::list1<boost::_bi::list_av_1<boost::_bi::bind_t<void,void (__cdecl *)(int),boost::_bi::list1<boost::_bi::list_av_1<int>::B1>>>::B1> ] c:/workspace\ main.cpp(36) : see reference to class template instantiation 'boost::_bi::bind_t<R,F,L>' being compiled with [ R=void, F=void (__cdecl *)(boost::_bi::bind_t<void,void (__cdecl *)(int),boost::_bi::list1<boost::_bi::list_av_1<int>::B1>>), L=boost::_bi::list1<boost::_bi::list_av_1<boost::_bi::bind_t<void,void (__cdecl *)(int),boost::_bi::list1<boost::_bi::list_av_1<int>::B1>>>::B1> ] c:/workspace\ main.cpp(46) : see reference to function template instantiation 'void callFooWith<boost::_bi::bind_t<R,F,L>>(T_Param)' being compiled with [ R=void, F=void (__cdecl *)(int), L=boost::_bi::list1<boost::_bi::list_av_1<int>::B1>, T_Param=boost::_bi::bind_t<void,void (__cdecl *)(int),boost::_bi::list1<boost::_bi::list_av_1<int>::B1>> ]

2 1

Q: BOOST.TEST VC7 mt gd worked on 1.30, fails on 1.31
by Dan Dimerman 16 Nov '04

16 Nov '04

Hello, I just wanted to ask about your experience with the latest (1.31) Boost.Test module. I had several unit tests written with Boost 1.30, and they worked fine. Now I upgraded to 1.31 and the unit test fails in a weird way: It seems to crash while DEALLOCATING the unit tests themselves. Call stack shows it fails on an ASSERT in <xmemory> void deallocate( pointer _Ptr, size_type ). Debugger shows that _ptr points to one of my unit test functions. I am linking with libboost_unit_test_framework-vc7-mt-gd-1_31.lib, libboost_date_time-vc7-mt-gd-1_31.lib, and xerces-c_2.lib (among others). Code generation: Multi-threaded Debug (/MTd). Any help would be appreciated... Thanks in advance.

2 1

install-name for OS X dylibs
by goochrules! 15 Nov '04

15 Nov '04

I was unable to find any reference to this on boost.org or in the mailing lists, so... Is there any way to specifiy the '-install_name' for ld to use when building boost for OS X? I see that currently the relative path to some sort of staging area in effect is used, for example, for libboost_thread-1_31.dylib, otool -L returns (among others): > otool -L libboost_thread-1_31.dylib libboost_thread-1_31.dylib: bin/boost/libs/thread/build/libboost_thread.dylib/darwin/release/shared-linkable-true/libboost_thread-1_31.dylib (compatibility version 0.0.0, current version 0.0.0) Alternatively, I suppose I could link the .o files (in $boost/bin/boost/thread/build/libboost_thread.dylib/darwin/release/shared-linkable-true/) manually; is there anything I should look out for if I choose this path? Are there any other object files I need to include? -- Matthew Peltzer -- goochrules(a)gmail.com

1 0

boost bind question, can it create a functor with more arguments than needed 2
by gast 128 15 Nov '04

15 Nov '04

Dear All, Thank you this works! Didn't expect this... Wkr, me _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.com/

1 0

Boost and VC++: cannot open file 'libboost_date_time-vc71-mt-sgd-1_31.lib'
by Christopher Athaide 15 Nov '04

15 Nov '04

I have just started using the Boost libraries in VC++.NET - Please bear with me if this seems too simple. I am having trouble compiling this simple class library. //------------------------------------------------- #include "boost/date_time/gregorian/gregorian.hpp" #include "boost/date_time/date_parsing.hpp" namespace First { typedef boost::gregorian::date customDate; } //------------------------------------------------- I get the error message: "cannot open file 'libboost_date_time-vc71-mt-sgd-1_31.lib' " I saw the note by John Maddock and I tried to include this code at the start of the file but it did not help. // // Automatically link to the correct build variant where possible. // #if !defined(BOOST_ALL_NO_LIB) && !defined(BOOST_WHATEVER_NO_LIB) && !defined(BOOST_WHATEVER_SOURCE) // // Set the name of our library, this will get undef'ed by auto_link.hpp // once it's done with it: // #define BOOST_LIB_NAME boost_whatever // // If we're importing code from a dll, then tell auto_link.hpp about it: // #if defined(BOOST_ALL_DYN_LINK) || defined(BOOST_WHATEVER_DYN_LINK) # define BOOST_DYN_LINK #endif // // And include the header that does the work: // #include <boost/config/auto_link.hpp> #endif // auto-linking disabled Clearly I am missing something (maybe quite simple.) I appreciate any help in this matter. Thanks Chris

2 2