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

boost::transitive_closure() and “error: no matching function for call to ‘vertices(const std::vector<std::vector<long unsigned int>…”
by Jacob Lidman 04 Feb '12

04 Feb '12

Hi, I posted a question regarding an error I've received with boost::transitive_closure() to stackoverflow (http://stackoverflow.com/questions/8976812/boosttransitive-closure-and-erro…) Since I didn't receive any comments I'm now trying this mailing list. In short I'm getting an error about a missing function when I'm trying to compute the transitive closure. The code in question is ... ------------- 1: #include <boost/graph/vector_as_graph.hpp> 2: #include <boost/graph/adjacency_list.hpp> 3: #include <boost/graph/transitive_closure.hpp> 10: boost::adjacency_list<boost::setS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_name_t, ContainerStruct *> > gTC, g = create_CSgraph(); 11: boost::transitive_closure(g, gTC); ------------- ... where "ContainerStruct" is a structure for holding various data and create_CSgraph() is a function for initializing a graph object. The error I'm getting is... ------------- /home/lidman/boost_1_48_0/BUILD/include/boost/graph/depth_first_search.hpp: In function ‘void boost::depth_first_search(const VertexListGraph&, const boost::bgl_named_params<P, T, R>&) [with VertexListGraph = std::vector<std::vector<long unsigned int, std::allocator<long unsigned int> >, std::allocator<std::vector<long unsigned int, std::allocator<long unsigned int> > > >, P = boost::topo_sort_visitor<std::back_insert_iterator<std::vector<long unsigned int, std::allocator<long unsigned int> > > >, T = boost::graph_visitor_t, R = boost::bgl_named_params<boost::typed_identity_property_map<long unsigned int>, boost::vertex_index_t, boost::no_property>]’: /home/lidman/boost_1_48_0/BUILD/include/boost/graph/topological_sort.hpp:65: instantiated from ‘void boost::topological_sort(VertexListGraph&, OutputIterator, const boost::bgl_named_params<P, T, R>&) [with VertexListGraph = std::vector<std::vector<long unsigned int, std::allocator<long unsigned int> >, std::allocator<std::vector<long unsigned int, std::allocator<long unsigned int> > > >, OutputIterator = std::back_insert_iterator<std::vector<long unsigned int, std::allocator<long unsigned int> > >, P = boost::typed_identity_property_map<long unsigned int>, T = boost::vertex_index_t, R = boost::no_property]’ /home/lidman/boost_1_48_0/BUILD/include/boost/graph/transitive_closure.hpp:120: instantiated from ‘void boost::transitive_closure(const Graph&, GraphTC&, G_to_TC_VertexMap, VertexIndexMap) [with Graph = boost::adjacency_list<boost::listS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_name_t, ContainerStruct*, boost::no_property>, boost::no_property, boost::no_property, boost::listS>, GraphTC = boost::adjacency_list<boost::listS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_name_t, ContainerStruct*, boost::no_property>, boost::no_property, boost::no_property, boost::listS>, G_to_TC_VertexMap = boost::iterator_property_map<long unsigned int*, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, ContainerStruct*, boost::no_property>, long unsigned int>, long unsigned int, long unsigned int&>, VertexIndexMap = boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, ContainerStruct*, boost::no_property>, long unsigned int>]’ /home/lidman/boost_1_48_0/BUILD/include/boost/graph/transitive_closure.hpp:263: instantiated from ‘void boost::transitive_closure(const Graph&, GraphTC&) [with Graph = CFG, GraphTC = CFG]’ test.C:11: instantiated from here /home/lidman/boost_1_48_0/BUILD/include/boost/graph/depth_first_search.hpp:291: error: no matching function for call to ‘vertices(const std::vector<std::vector<long unsigned int, std::allocator<long unsigned int> >, std::allocator<std::vector<long unsigned int, std::allocator<long unsigned int> > > >&)’ /home/lidman/boost_1_48_0/BUILD/include/boost/graph/topological_sort.hpp:65: instantiated from ‘void boost::topological_sort(VertexListGraph&, OutputIterator, const boost::bgl_named_params<P, T, R>&) [with VertexListGraph = std::vector<std::vector<long unsigned int, std::allocator<long unsigned int> >, std::allocator<std::vector<long unsigned int, std::allocator<long unsigned int> > > >, OutputIterator = std::back_insert_iterator<std::vector<long unsigned int, std::allocator<long unsigned int> > >, P = boost::typed_identity_property_map<long unsigned int>, T = boost::vertex_index_t, R = boost::no_property]’ /home/lidman/boost_1_48_0/BUILD/include/boost/graph/transitive_closure.hpp:120: instantiated from ‘void boost::transitive_closure(const Graph&, GraphTC&, G_to_TC_VertexMap, VertexIndexMap) [with Graph = boost::adjacency_list<boost::listS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_name_t, ContainerStruct*, boost::no_property>, boost::no_property, boost::no_property, boost::listS>, GraphTC = boost::adjacency_list<boost::listS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_name_t, ContainerStruct*, boost::no_property>, boost::no_property, boost::no_property, boost::listS>, G_to_TC_VertexMap = boost::iterator_property_map<long unsigned int*, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, ContainerStruct*, boost::no_property>, long unsigned int>, long unsigned int, long unsigned int&>, VertexIndexMap = boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, ContainerStruct*, boost::no_property>, long unsigned int>]’ /home/lidman/boost_1_48_0/BUILD/include/boost/graph/transitive_closure.hpp:263: instantiated from ‘void boost::transitive_closure(const Graph&, GraphTC&) [with Graph = CFG, GraphTC = CFG]’ test.C:11: instantiated from here /home/lidman/boost_1_48_0/BUILD/include/boost/graph/depth_first_search.hpp:297: error: no matching function for call to ‘vertices(const std::vector<std::vector<long unsigned int, std::allocator<long unsigned int> >, std::allocator<std::vector<long unsigned int, std::allocator<long unsigned int> > > >&)’ /home/lidman/boost_1_48_0/BUILD/include/boost/graph/named_function_params.hpp: In static member function ‘static boost::shared_array_property_map<Value, typename boost::remove_const<typename boost::detail::override_const_property_t<typename boost::parameter::value_type<ArgPack, boost::graph::keywords::tag::vertex_index_map, int>::type, boost::vertex_index_t, Graph, boost::detail::parameter_exists<ArgPack,boost::graph::keywords::tag::vertex_index_map>::value>::result_type>::type> boost::detail::map_maker_helper<false, Graph, ArgPack, Value, PM>::make_map(const Graph&, Value, const PM&, const ArgPack&) [with Graph = std::vector<std::vector<long unsigned int, std::allocator<long unsigned int> >, std::allocator<std::vector<long unsigned int, std::allocator<long unsigned int> > > >, ArgPack = boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::visitor, const boost::topo_sort_visitor<std::back_insert_iterator<std::vector<long unsigned int, std::allocator<long unsigned int> > > > >, boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::vertex_index_map, const boost::typed_identity_property_map<long unsigned int> >, boost::parameter::aux::empty_arg_list> >, Value = boost::default_color_type, PM = int]’: /home/lidman/boost_1_48_0/BUILD/include/boost/graph/named_function_params.hpp:520: instantiated from ‘static typename boost::detail::map_maker_helper<boost::detail::map_maker<Graph, ArgPack, MapTag, ValueType>::has_map, Graph, ArgPack, ValueType, typename boost::remove_const<typename boost::parameter::value_type<ArgPack, MapTag, int>::type>::type>::map_type boost::detail::map_maker<Graph, ArgPack, MapTag, ValueType>::make_map(const Graph&, const ArgPack&, ValueType) [with Graph = std::vector<std::vector<long unsigned int, std::allocator<long unsigned int> >, std::allocator<std::vector<long unsigned int, std::allocator<long unsigned int> > > >, ArgPack = boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::visitor, const boost::topo_sort_visitor<std::back_insert_iterator<std::vector<long unsigned int, std::allocator<long unsigned int> > > > >, boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::vertex_index_map, const boost::typed_identity_property_map<long unsigned int> >, boost::parameter::aux::empty_arg_list> >, MapTag = boost::graph::keywords::tag::color_map, ValueType = boost::default_color_type]’ /home/lidman/boost_1_48_0/BUILD/include/boost/graph/named_function_params.hpp:535: instantiated from ‘typename boost::detail::map_maker<Graph, ArgPack, MapTag, ValueType>::map_type boost::detail::make_property_map_from_arg_pack_gen<MapTag, ValueType>::operator()(const Graph&, const ArgPack&) const [with Graph = std::vector<std::vector<long unsigned int, std::allocator<long unsigned int> >, std::allocator<std::vector<long unsigned int, std::allocator<long unsigned int> > > >, ArgPack = boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::visitor, const boost::topo_sort_visitor<std::back_insert_iterator<std::vector<long unsigned int, std::allocator<long unsigned int> > > > >, boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::vertex_index_map, const boost::typed_identity_property_map<long unsigned int> >, boost::parameter::aux::empty_arg_list> >, MapTag = boost::graph::keywords::tag::color_map, ValueType = boost::default_color_type]’ /home/lidman/boost_1_48_0/BUILD/include/boost/graph/depth_first_search.hpp:297: instantiated from ‘void boost::depth_first_search(const VertexListGraph&, const boost::bgl_named_params<P, T, R>&) [with VertexListGraph = std::vector<std::vector<long unsigned int, std::allocator<long unsigned int> >, std::allocator<std::vector<long unsigned int, std::allocator<long unsigned int> > > >, P = boost::topo_sort_visitor<std::back_insert_iterator<std::vector<long unsigned int, std::allocator<long unsigned int> > > >, T = boost::graph_visitor_t, R = boost::bgl_named_params<boost::typed_identity_property_map<long unsigned int>, boost::vertex_index_t, boost::no_property>]’ /home/lidman/boost_1_48_0/BUILD/include/boost/graph/topological_sort.hpp:65: instantiated from ‘void boost::topological_sort(VertexListGraph&, OutputIterator, const boost::bgl_named_params<P, T, R>&) [with VertexListGraph = std::vector<std::vector<long unsigned int, std::allocator<long unsigned int> >, std::allocator<std::vector<long unsigned int, std::allocator<long unsigned int> > > >, OutputIterator = std::back_insert_iterator<std::vector<long unsigned int, std::allocator<long unsigned int> > >, P = boost::typed_identity_property_map<long unsigned int>, T = boost::vertex_index_t, R = boost::no_property]’ /home/lidman/boost_1_48_0/BUILD/include/boost/graph/transitive_closure.hpp:120: instantiated from ‘void boost::transitive_closure(const Graph&, GraphTC&, G_to_TC_VertexMap, VertexIndexMap) [with Graph = boost::adjacency_list<boost::listS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_name_t, ContainerStruct*, boost::no_property>, boost::no_property, boost::no_property, boost::listS>, GraphTC = boost::adjacency_list<boost::listS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_name_t, ContainerStruct*, boost::no_property>, boost::no_property, boost::no_property, boost::listS>, G_to_TC_VertexMap = boost::iterator_property_map<long unsigned int*, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, ContainerStruct*, boost::no_property>, long unsigned int>, long unsigned int, long unsigned int&>, VertexIndexMap = boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, ContainerStruct*, boost::no_property>, long unsigned int>]’ /home/lidman/boost_1_48_0/BUILD/include/boost/graph/transitive_closure.hpp:263: instantiated from ‘void boost::transitive_closure(const Graph&, GraphTC&) [with Graph = CFG, GraphTC = CFG]’ test.C:11: instantiated from here /home/lidman/boost_1_48_0/BUILD/include/boost/graph/named_function_params.hpp:499: error: no matching function for call to ‘num_vertices(const std::vector<std::vector<long unsigned int, std::allocator<long unsigned int> >, std::allocator<std::vector<long unsigned int, std::allocator<long unsigned int> > > >&)’ ------------- From this page (http://boost.2283326.n4.nabble.com/Problem-in-using-Transitive-closure-on-L…) I learned that including "boost/graph/vector_as_graph.hpp" before "boost/graph/transitive_closure.hpp" might do the trick. Unfortunately that doesn't seem to help me. For completeness I'm using GCC 4.1.2 20080704 (Red Hat 4.1.2-51) and Boost 1.48.0 on a x86_64 linux machine. GCC 4.5.0 seems to give me the same error message. Is there a newer workaround for this problem? Best regards, Jacob Lidman

2 1

msvc linker wants to prepend "lib" to library names
by Andy Falanga (afalanga) 03 Feb '12

03 Feb '12

Hi everyone, I'm working through an issue which no longer seems to be unique to me. I've found several instances of people having this same issue. As the subject suggests, I'm in a situation where the msvc linker is prepending "lib" to the referenced boost library (in this case, regex) for the project. However, the interesting thing is, it's not happening for me, only for others on my team. On my dev box, the project builds just fine. To the best of my knowledge, I have pushed up all required changes (I added the need for regex with some changes I put in place) to the Team Foundation Server. However, when my colleagues checkout the latest revision of this new solution, they are unable to build because of this. The simple question is, why is this happening? I'd like to understand what's going on rather than simply being told how to fix it. From the many hits I've looked through, I've tried a couple of things but they do not seem to fix the problem. I found a link that said the problem is because I needed to additionally link with comsupp.lib (I found an article on MS that instructs to link with comsuppw.lib or comsuppdw.lib instead) to which I tried, but that hasn't fixed the issue. I found another that suggested I define the macro BOOST_ALL_DYN_LINK in the source code, but this hasn't helped either. Our environment is that we've installed boost 1.47 via the installer from boost-pro. The solution has all appropriate directories mapped (include and library directories). Are there property settings in my project that I should look for? I've been able to glean that this problem has something to do with static vs. dynamic linking. Should I check in my linker options for something? I have done that extensively already, but I'm not a strong MS developer and could have easily missed something. Thanks, Andy

3 4

[Dynamic Bitset][Boost 1.44.0] Compilation error.
by mik 03 Feb '12

03 Feb '12

I'm using the dynamic biset in a project, but when I compile my code in debug with Visual Studio 2008, I get this error: C:\REPOSI~1\Boost\BOOST_~2\boost/dynamic_bitset/dynamic_bitset.hpp(1727) : error C2668: '_wassert' : ambiguous call to overloaded function C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\assert.h(28): could be 'void _wassert(const wchar_t *,const wchar_t *,unsigned int)' C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\assert.h(28): or 'void `anonymous-namespace'::_wassert(const wchar_t *,const wchar_t *,unsigned int)' while trying to match the argument list '(const wchar_t [44], const wchar_t [67], int)' The only solution that I found is to comment the line. Do you have a better one? Thank you in advance. Mirko **

1 0

boost thread: ‘internal_mutex’ was not declared in this scope
by Thijs (M.A.) van den Berg 03 Feb '12

03 Feb '12

I' stuck with this strange issue with boost thread 1.48 when compiling this minimal example: #include <boost/thread/thread.hpp> int main() { retun 0; } with gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix I get this error, .. I can't find anything via google… /usr/local/include/boost/thread/pthread/condition_variable.hpp: In member function ‘void boost::condition_variable::wait(boost::unique_lock<boost::mutex>&)’: /usr/local/include/boost/thread/pthread/condition_variable.hpp:53: error: ‘internal_mutex’ was not declared in this scope

1 0

Boost with C code.. please help...
by Kamalkishor 02 Feb '12

02 Feb '12

Hello, I am very new to Boost. I have to write unit test cases in order to increase the code coverage of a C source code. I am not getting the approach to start writing the test cases. As it is a code C code, there are huge number of functions, one calling the other, and a lot of global variables. Can anyone please help me out to get the approach to start writing Unit test cases. And, I have used a "c++" compiler for compiling small Boost programs. I am getting error while using "GCC" compiler. Can we use GCC compiler for compiling Boost program? How can we do this? Please help me out. Thanks in advance. Thanks, Kamalkishor.

3 2

multi_array and move semantics
by Helmut Zeisel 02 Feb '12

02 Feb '12

Does multi_array support move semantics? If not, are there any plans to add move semantics? Helmut -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://www.gmx.net/de/go/freephone/

2 1

solved - Can't dynamically load shared lib that is statically linked to boost thread
by Greg Carter 02 Feb '12

02 Feb '12

Well it turns out despite not receiving any link errors I wasn't linking to libboost_thread.a as I thought I was. On Windows this seems to be handled by the auto link facility and I figured the same on linux. Which explains why when I explicitly link to the shared libboost_thread.so everything worked. However explicitly linking to the static libboost_thread.a resulted in a link error of relocation R_X86_64_32 ... recompile with -fPIC. Doing a custom compile with the fPIC option set fixed that. ./bjam -a --prefix=/usr/local/boost_1_47_0 cxxflags=-fPIC --with-thread This only seems to have updated the stage directory though and not boost_root/lib. Not sure why that is as I didn't pass the --stage option.

1 0

[Spirit] qi::parse at translation unit global scope?
by Olaf Meeuwissen 01 Feb '12

01 Feb '12

I noticed this when I played around with wrapping qi::parse() in a parse() function that does some things before and after qi::parse(). My code had been calling qi::parse(), with the `qi::` namespace prefix, everywhere so I removed from a few calls and compiled before adding a parse() declaration. Lo and behold, compilation unexpectedly succeeded. I've reduced the behaviour in a minimalistic sample program (attached). I expect their to be *no* parse() function within the scope of main(). Can anyone clarify why the compiler has no trouble finding one and which one it finds? Adding a global scope operator to the call, i.e. saying ::parse(), does result in the expected compile error. Using Boost 1.46.1, gcc 4.6.2 on Debian wheezy. Thanks in advance, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962

4 4

problems with C++ integer types
by Robert Ramey 01 Feb '12

01 Feb '12

I'm very confused about a number of things related to C++ standard and boost libraries dealing with numeric types. Here are a few things that I'm not getting. a) The standard says in section 18.3.2.1 "Specializations shall be provided for each arithmetic type, both floating point and integer, including bool. The member is_specialized shall be true for all such specializations of numeric_limits." ... "Non-arithmetic standard types, such as complex<T> (26.4.2), shall not have specializations." and it section 18.3.2.4 numeric_limits members static constexpr bool is_bounded; "True if the set of values representable by the type is finite. [ Note: All built-in types are bounded. This member would be false for arbitrary precision types.-end note ]" So the question is: if one makes a "numeric type" like std::complex (or safe integer which I'm interested in right now). Should one define a specialization for this new type? The working is pretty specific, but then I can't see why "is_bounded" is in there since all built-in arithmetic types are bounded. Oh I see this now: Required by LIA-1. b) boost/type_traits/is_integral.hpp This file just specializes each arithmetic type supported by the implementation. question:Why isn't it just implemented in terms of numeric limits so that every thing is always consistent and never "out of sync" It's implementation returns true for only the built in types so it seems to me it should be repeating what ever happens to already be in numeric_types. c) my real interest is to implement a type "safe_integer" which can be used anywhere an integer is used but will trap errors which occur in the course of implicit conversions and assignements. If I don't specialize numeric_limits for my new "safe_integer" certain type_traits like is_signed won't work for it. If I do - them I"m out of sync with is_integral.hpp and likely out of conformance with the standard - though I'm not sure what the implications of that might be. I'm aware that there is related work going on here - bigint and arbitrary length integers. How do the authors of these libraries plan to address this. There are other cases applications where this would also come up such as modular integer<modulus> , safe_integer_range<max, min> and who know what else. Any useful information/insight would be appreciated. Robert Ramey

8 12

Re: [Boost-users] Need help with Errors in boost MPL tutorials
by Linh Khanh ha 01 Feb '12

01 Feb '12

> There are far more than just two placeholders in Boost. AFAIK Phoenix, > Lambda and Bind come with their own. The mpl placeholder is different > though: It is a placeholder for a type (it's a meta-programming > library after all) and not for a value. Try to write a MPL lambda, > that might clear up some of the confusion. > -- Philipp Moeller, GeometryFactory That clears a lot of confusion from me. So again, mpl::lambda is also different from boost::lambda is that right (and also the lambda from c++11x) ? These are quite new terms for me. Would be great if someone could give me some references why they are different and should be implemented separately.

2 1