March 2011 - Boost-users - lists.boost.org

[graph] Is reverse_graph<> read-only?
by al.zatv 08 Mar '11

08 Mar '11

Hello! Is reverse_graph<> in Boost::Graph Library, read-only? I just can't beleive it:) Can it be fixed?

3 13

FW: compiling parallel boost graph lib
by Xin Sui 08 Mar '11

08 Mar '11

Hi: When I compile parallel boost graph library, I encounter the following errors: parallel-bgl-0.7.0/boost/graph/distributed/adjlist/serialization.hpp: In function `std::vector<int, std::allocator<int> > boost::detail::parallel::available_process_files(const std::string&)': parallel-bgl-0.7.0/boost/graph/distributed/adjlist/serialization.hpp:97: error: conversion from `boost::filesystem3::path' to non-scalar type `std::basic_string<char, std::char_traits<char>, std::allocator<char> >' requested make[2]: *** [libs/graph_parallel/test/CMakeFiles/adjlist_build_test.dir/adjlist_build_test.cpp.o] Error 1 make[1]: *** [libs/graph_parallel/test/CMakeFiles/adjlist_build_test.dir/all] Error 2 The CMake found the following software: gcc (GCC) 3.4.6, Boost version: 1.46.0 and openmpi 1.3, c++ (GCC) 3.4.6 20060404 (Red Hat 3.4.6-11) Do you guys have an idea what the problem is? Thanks Xin

2 1

Boost Interprocess error on Solaris sun studio 12
by aidan mcgurn 08 Mar '11

08 Mar '11

Hi, Currently my company are having issues compiling Boost Interprocess 1.42 on Solaris sun Studio. I see from Boost documentation that this compiler is not listed as having been used to build Interprocess: i.e. * Visual 7.1 Windows XP * Visual 8.0 Windows XP * GCC 4.1.1 MinGW * GCC 3.4.4 Cygwin * Intel 9.1 Windows XP * GCC 4.1.2 Linux * GCC 3.4.3 Solaris 11 * GCC 4.0 MacOs 10.4.1 I have also seen from this next thread that there is a bug logged against this issue as posted from someone with a similar issue: http://forums.oracle.com/forums/thread.jspa?threadID=1992480&tstart=45 "Unfortunately, your problem is one of the outstanding issues with Boost that we have not yet resolved. This one is bug number 6954828, generated internally, and not visible at bugs.sun.com. Fixing bugs that prevent Boost from compiling is a priority item for us, but I can't predict when a fix for this problem will be available." This was posted a year ago so i am wondering has this been fixed in recent Boost editions or plans to? If not is there a recommended workaround? (outside the posts suggested flag changes "-D_POSIX_C_SOURCE=4 -D_XPG4 -D_XPG4_2" which are unpredictable to other parts of our system) thanks for any suggestions, /aidan ======= Errors i see: "/spare/integra/thirdparty/include/boost/interprocess/mapped_region.hpp", line 549: Error: Formal argument 1 of type char* in call to shmdt(char*) is being passed void*. "/spare/integra/thirdparty/include/boost/interprocess/shared_memory_object.hpp", line 284: Error: The function "shm_open" must have a prototype. "/spare/integra/thirdparty/include/boost/interprocess/shared_memory_object.hpp", line 307: Error: The function "shm_unlink" must have a prototype.

3 5

[Regex] Search Substring
by S Nagre 08 Mar '11

08 Mar '11

Hi, I am new to boost Libraries and I am trying to find a substring using Boost::Regex Lets say I want to find string "Hello" in "Hello world". std::string completeStr = "Hello World"; std::string::const_iterator startOffset = completeStr.begin(); std::string::const_iterator endOffset = completeStr.end(); std::string searchWord= "Hello"; boost::regex expression(searchWord); boost::match_flag_type flags = boost::match_any; while(boost::regex_search(startOffset, endOffset, what, expression, flags)) { int32 position = what.position(1); int32 len = what[1].length(); } but value of this position and length value is coming out to be -1. It is not able to find this substring, Could anyone tell me what I am doing wrong ? Subhash

3 3

multi_index_container insert is excruciatingly slow
by Georges Dupret 08 Mar '11

08 Mar '11

Hi! In spite of compiling with NDEBUG set: g++ -Wall -D_REENTRANT -msse2 -mfpmath=sse -Wno-deprecated -DNDEBUG -c -O3 -I/home/gdupret/.local/lib64/include/ -MMD -MP -MF build/Release/GNU-Linux-x86/Model.o.d -o build/Release/GNU-Linux-x86/Model.o Model.cpp, inserting into a multi_index_container is excruciatingly slow. I have a large nbr. of elements to insert (10^5) but even the first 1000 are very slow. I also set: #ifndef NDEBUG #define NDEBUG #endif #ifdef BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING #undef BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING #endif #ifdef BOOST_MULTI_INDEX_ENABLE_SAFE_MODE #undef BOOST_MULTI_INDEX_ENABLE_SAFE_MODE #endif in the header calling the multi_index_container, but I see no change. Any suggestion on how I should do? Best ge

4 3

[uBLAS] Results of different size matrix addition
by Ryan 08 Mar '11

08 Mar '11

According to the preconditions for binary matrix operations both matrix must have the same size ( http://www.boost.org/doc/libs/1_46_0/libs/numeric/ublas/doc/matrix_expressi…) What runtime error should I expected if the matrix sizes are not the same? Ryan

2 1

[ICL] More compilation questions/problems
by John Reid 08 Mar '11

08 Mar '11

#include <boost/icl/interval.hpp> template< typename IntervalT > void check_contains() { IntervalT interval; typedef typename IntervalT::domain_type domain_t; ::boost::icl::contains( interval, domain_t() ); } void h() { namespace icl = ::boost::icl; check_contains< icl::continuous_interval< float > >(); check_contains< icl::discrete_interval< int > >(); check_contains< icl::right_open_interval< float > >(); check_contains< icl::left_open_interval< float > >(); check_contains< icl::closed_interval< float > >(); check_contains< icl::open_interval< float > >(); } The last 2 lines in h() do not compile whilst the preceeding 4 do. Is this by design or a bug? Testing elements for membership of a closed or open interval seems natural enough. I'm using gcc 4.4.3. Thanks, John.

2 5

[general] is there a noop deallocator in boost?
by Mostafa 07 Mar '11

07 Mar '11

Hi all, I'm interested in a noop deallocator for use in shared_ptr, but can't find one in boost, so does anyone know of one? (I know it's trivial to write one, but that doesn't out weight the convenience of using a standardized one.) Thanks, Mostafa

3 4

[ptr_container] compiler error with BOOST_RESULT_OF_USE_DECLTYPE
by Nathan Ridge 07 Mar '11

07 Mar '11

Hello, The following code: #include <boost/ptr_container/ptr_set.hpp> struct A { bool operator<(const A&) const; }; int main() { boost::ptr_set<A> s; return 0; } gives the following compiler errors when compiling with BOOST_RESULT_OF_USE_DECLTYPE defined: In file included from ../../lib/boost- 1.45/boost/preprocessor/iteration/detail/iter/forward1.hpp:52:0, from ../../lib/boost-1.45/boost/utility/result_of.hpp:92, from ../../lib/boost-1.45/boost/ptr_container/indirect_fun.hpp:23, from ../../lib/boost-1.45/boost/ptr_container/ptr_set.hpp:19, from test.cpp:1: ../../lib/boost-1.45/boost/utility/detail/result_of_iterate.hpp: In instantiation of 'boost::detail::cpp0x_result_of_impl<less<A>(A &)>': ../../lib/boost-1.45/boost/utility/detail/result_of_iterate.hpp:44:8: instantiated from 'boost::result_of<less<A>(A &)>' ../../lib/boost-1.45/boost/ptr_container/indirect_fun.hpp:107:9: instantiated from 'boost::void_ptr_indirect_fun<less<A>, A, A>' stl_tree.h:462:31: instantiated from '_Rb_tree< void *, void *, _Identity<void *> , boost::void_ptr_indirect_fun<less<A>, A, A> >' stl_set.h:112:17: instantiated from 'set< void *, boost::void_ptr_indirect_fun<less<A>, A, A> >' ../../lib/boost-1.45/boost/ptr_container/ptr_set_adapter.hpp:40:21: instantiated from 'boost::ptr_container_detail::set_config< A, set<void *, boost::void_ptr_indirect_fun<less<A>, A, A> >, true >' ../../lib/boost-1.45/boost/ptr_container/detail/reversible_ptr_container.hpp:87:59: instantiated from 'boost::ptr_container_detail::reversible_ptr_container< boost::ptr_container_detail::set_config< A, set<void *, boost::void_ptr_indirect_fun<less<A>, A, A> >, true >, boost::heap_clone_allocator >' ../../lib/boost-1.45/boost/ptr_container/detail/associative_ptr_container.hpp:32:11: instantiated from 'boost::ptr_container_detail::associative_ptr_container< boost::ptr_container_detail::set_config< A, set<void *, boost::void_ptr_indirect_fun<less<A>, A, A> >, true >, boost::heap_clone_allocator >' ../../lib/boost-1.45/boost/ptr_container/ptr_set_adapter.hpp:122:11: instantiated from 'boost::ptr_container_detail::ptr_set_adapter_base< A, set<void *, boost::void_ptr_indirect_fun<less<A>, A, A> > , boost::heap_clone_allocator, true >' ../../lib/boost-1.45/boost/ptr_container/ptr_set_adapter.hpp:299:11: instantiated from 'boost::ptr_set_adapter< A, set<void *, boost::void_ptr_indirect_fun<less<A>, A, A> > , boost::heap_clone_allocator, true >' ../../lib/boost-1.45/boost/ptr_container/ptr_set.hpp:33:11: instantiated from 'boost::ptr_set<A>' ../shared/test/test.cpp:10:23: instantiated from here ../../lib/boost-1.45/boost/utility/detail/result_of_iterate.hpp:70:69: error: no match for call to '(less<A>) (A &)' stl_function.h:230:12: candidate is: stl_function.h:233:7: bool less<A>::operator()(const A &, const A &) const stl_function.h:233:7: candidate expects 2 arguments, 1 provided I am compiling with g++ 4.5 with the --std=c++0x flag. The error goes away if I do not define BOOST_RESULT_OF_USE_DECLTYPE (but I need this define for other things). Am I doing something wrong or is this a bug? Thanks, Nate.

4 17

spirit classic - matching end of file space
by Noah Roberts 07 Mar '11

07 Mar '11

I have a parser that works great except if there's space at the end of the stream. I can't seem to come up with a manner to match that space. The file consists of a header block followed by any number of "shape" blocks. I'm calling the parser with: boost::spirit::classic::parse(begin, end, grammar, boost::spirit::classic::space_p) My file grammar looks like so: shape_file = !( header[assign_a(self.header_was_read, t)][assign_a (self.read_header, shape_file_header_grammar::current_header)] ) >> *( shape[push_back_a(self.read_shapes, shape_grammar::current_shape)] ) ; The parser seems to break down because space at the end of the stream makes it try to read another shape. My shape grammar looks like so: shape_block = // := <shape_header> "Begin" <element>* "End" (shape_header | shapeheader_error) >> (as_lower_d["begin"] | begin_error) >> *element >> as_lower_d["end"] ; I've tried adding '*space_p' at the end of both of the above. I've also tried '*lexeme_p[space_p]' in both. Neither fixes the problem. I've left out the various other bits of the grammars because it all works, with this minor issue about end of file space. I'm hoping that it's irrelevant to the problem. How might I go about gobbling up any end-of-file spaces in this setup? -- http://crazycpp.wordpress.com/

1 1