- Boost-users - lists.boost.org

[MultiIndex] strange problem with simple use of member key extractor
by John M. Dlugosz 18 Jan '13

18 Jan '13

namespace bmi = boost::multi_index; .... bmi::ordered_non_unique< bmi::member< ItemBase, unsigned, &ItemBase::my_member > >, // ordered_non_unique .... I'm getting a compiler error on VS10 from template<class Class,typename Type,Type Class::*PtrToMember> struct non_const_member_base { .... Type& operator()(const ChainedPtr& x)const { return operator()(*x); } boost/multi_index/member.hpp(105): error C2440: 'return' : cannot convert from 'const unsigned int' to 'unsigned int &' It also tells me that the ChainedPtr is a shared_ptr to a const ItemBase, and I can see that _none_ of the operator()'s in that class return a non-reference. But if the compiler is already thinking ref-becomes-lvalue and leaves that out, the next form const Type& operator()(const Class& x,int=0)const { return x.*PtrToMember; } is a perfect match to *x and so I expect the return value to be in fact const (because the object being dereferencd was const) Any idea what's going on here, and what I might do about it? Our project is using Boost 1.49, though I didn't see anything in the release notes about changes to MultiIndex in later releases. —John

2 1

[BGL] Limited depth search without O(number_of_verices) complexity?
by Ilja Honkonen 18 Jan '13

18 Jan '13

Hello Is it possible to do a limited depth depth first search without using O(N) additional memory? The following code seems to visit only a part of the graph but it still requires O(N) memory for the external color map. Could that be avoided with an internal color map? I didn't manage to get depth_first_visit(...) to use an internal color map. Would the solution work also with other graph types besides <vecS, vecS, ...>? #include <iostream> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/depth_first_search.hpp> using namespace std; using namespace boost; struct custom_dfs_visitor : public default_dfs_visitor { template < typename Vertex, typename Graph > void discover_vertex(const Vertex& v, const Graph& g) const { cout << v << endl; } }; struct Terminator { template<class Vertex, class Graph> bool operator()(const Vertex& v, const Graph& g) { return v > 2; } }; int main() { typedef adjacency_list< vecS, vecS, undirectedS > Graph_T; Graph_T g(6); add_edge(0, 1, g); add_edge(1, 2, g); add_edge(2, 3, g); add_edge(3, 4, g); add_edge(4, 5, g); vector<default_color_type> color_map(num_vertices(g)); depth_first_visit( g, vertex(0, g), custom_dfs_visitor(), make_iterator_property_map( color_map.begin(), get(vertex_index, g), color_map[0] ), Terminator() ); cout << "size: " << color_map.size() << endl; return 0; } Thanks Ilja

3 6

[MultiIndex] stable? Please help
by John M. Dlugosz 18 Jan '13

18 Jan '13

earlier I posted a question as to whether a non-unique index in MultiIndex is "stable" with regards to insertion order. Can anyone speak to this?

1 0

boost::range RangeConcept problem.
by Hurcan Solter 17 Jan '13

17 Jan '13

The following snippet is the mock-up of the problem I am having in order to be able to reproduce. -------------------------------------------------------------------------------- #include <iostream> #include <boost/range.hpp> #include <boost/range/adaptors.hpp> #include <boost/range/algorithm.hpp> #include <boost/bind.hpp> #include <boost/assign.hpp> using namespace boost::assign; struct wxSize { wxSize(int height=0,int width=0):m_height(height),m_width(width) { } int GetWidth() const {return m_width;} int m_height; int m_width; }; class wxWindowBase { public: wxSize GetTextExtent(const std::string val) { return wxSize(0,val.length()); } void DoLayout(std::vector<std::string> m_FilteredItems) { using boost::adaptors::transformed; wxSize longest = *boost::max_element(m_FilteredItems | transformed(boost::bind(&wxWindowBase::GetTextExtent,this,_1)), boost::bind(std::less<int>(),boost::bind(&wxSize::GetWidth,_1),boost::bind(&wxSize::GetWidth,_2))); std::cout <<longest.GetWidth(); } }; int main() { std::vector<std::string> input; input += "o","two","threexxx","four"; wxWindowBase window; window.DoLayout(input); } ----------------------------------------------------------------------------------------- The above code fails to compile on GCC4.7.2 and MSVC10 although it compiles and runs fine on clang3.3 >From what I understand ,transformed returns a Single Pass Range and max_element expects a ForwardRange and that's the gist of the problem.But it works for something like max_element(someint_vector | transformed(doubleit()),std::less<int>()); without problems. Is there a elegant way to achieve what I am trying to without using a intermediate container? Thanks in advance..

3 3

[thread][move] compiling move(thread) with Android NDK GCC4.7
by Igor R 17 Jan '13

17 Jan '13

Hello, I'm building my project with Android NDK toolchain (Boost1.51, GCC4.6 or GCC4.7), and I get the following error when trying to move thread. Is there any workaround for this issue? //... vector_.push_back(boost::move(thread(&func, arg))); //... try.cpp:86:62: error: no matching function for call to 'move(boost::thread)' try.cpp:86:62: note: candidates are: In file included from boost/thread/detail/move.hpp:20:0, from boost/thread/locks.hpp:11, from boost/thread/pthread/mutex.hpp:12, from boost/thread/mutex.hpp:16, from boost/thread/pthread/thread_data.hpp:13, from boost/thread/thread.hpp:17, from boost/thread.hpp:13, from try.h:3, from try.cpp:6: boost/move/move.hpp:324:97: note: template<class T> typename boost::move_detail::disable_if<boost::has_move_emulation_enabled_aux<T>, T&>::type boost::move(T&) boost/move/move.hpp:324:97: note: template argument deduction/substitution failed: boost/move/move.hpp: In substitution of 'template<class T> typename boost::move_detail::disable_if<boost::has_move_emulation_enabled_aux<T>, T&>::type boost::move(T&) [with T = boost::thread]': try.cpp:86:62: required from here boost/move/move.hpp:324:97: error: no type named 'type' in 'struct boost::move_detail::disable_if<boost::has_move_emulation_enabled_aux<boost::thread>, boost::thread&>' boost/move/move.hpp:330:96: note: template<class T> typename boost::move_detail::enable_if<boost::has_move_emulation_enabled<T>, boost::rv<T>&>::type boost::move(T&) boost/move/move.hpp:330:96: note: template argument deduction/substitution failed: boost/move/move.hpp: In substitution of 'template<class T> typename boost::move_detail::enable_if<boost::has_move_emulation_enabled<T>, boost::rv<T>&>::type boost::move(T&) [with T = boost::thread]': try.cpp:86:62: required from here boost/move/move.hpp:330:96: error: no type named 'type' in 'struct boost::move_detail::enable_if<boost::has_move_emulation_enabled<boost::thread>, boost::rv<boost::thread>&>' boost/move/move.hpp:336:96: note: template<class T> typename boost::move_detail::enable_if<boost::has_move_emulation_enabled<T>, boost::rv<T>&>::type boost::move(boost::rv<T>&) boost/move/move.hpp:336:96: note: template argument deduction/substitution failed: try.cpp:86:62: note: 'boost::thread' is not derived from 'boost::rv<T>' In file included from boost/thread/detail/move.hpp:20:0, from boost/thread/locks.hpp:11, from boost/thread/pthread/mutex.hpp:12, from boost/thread/mutex.hpp:16, from boost/thread/pthread/thread_data.hpp:13, from boost/thread/thread.hpp:17, from boost/thread.hpp:13, from try.h:3, from try.cpp:6: boost/move/move.hpp:943:6: note: template<class I, class O> O boost::move(I, I, O) boost/move/move.hpp:943:6: note: template argument deduction/substitution failed: try.cpp:86:62: note: candidate expects 3 arguments, 1 provided In file included from boost/thread/locks.hpp:11:0, from boost/thread/pthread/mutex.hpp:12, from boost/thread/mutex.hpp:16, from boost/thread/pthread/thread_data.hpp:13, from boost/thread/thread.hpp:17, from boost/thread.hpp:13, from try.h:3, from try.cpp:6: boost/thread/detail/move.hpp:55:124: note: typename boost::enable_if<boost::is_convertible<T&, boost::detail::thread_move_t<T> >, boost::detail::thread_move_t<T> >::type boost::move(T&) [with T = boost::thread; typename boost::enable_if<boost::is_convertible<T&, boost::detail::thread_move_t<T> >, boost::detail::thread_move_t<T> >::type = boost::detail::thread_move_t<boost::thread>] boost/thread/detail/move.hpp:55:124: note: no known conversion for argument 1 from 'boost::thread' to 'boost::thread&' In file included from boost/thread/locks.hpp:11:0, from boost/thread/pthread/mutex.hpp:12, from boost/thread/mutex.hpp:16, from boost/thread/pthread/thread_data.hpp:13, from boost/thread/thread.hpp:17, from boost/thread.hpp:13, from try.h:3, from try.cpp:6: boost/thread/detail/move.hpp:62:37: note: template<class T> boost::detail::thread_move_t<T> boost::move(boost::detail::thread_move_t<T>) boost/thread/detail/move.hpp:62:37: note: template argument deduction/substitution failed: try.cpp:86:62: note: 'boost::thread' is not derived from 'boost::detail::thread_move_t<T>'

3 11

FW: ASIO io_service performance under single or multiple io_services questions
by Bryan Fok 17 Jan '13

17 Jan '13

To asio users, I am confused by the results from my experiments with asio recently. Firstly, am I correct that, when OS I/O buffer is ready to be read, io_service will only pick an available thread from its thread pool to notify the socket's complete handler? For example, if I have a single io_service with 1 thread, and 100 udp sockets executed async_read_from. Hypothetically, if they all simultaneously ready to read from OS kernel buffer, would the io_service notify each socket's complete handler one per time because I only allocated 1 thread to it? Secondly, is it possible to assign workload to different cpu cores through asio? I did an experiment by creating 2 io_services in a program, and each associated with 50 udp sockets for receive same data at the same rate. My theory was that, 2 cores from my 8 cores i7 cpu would be utilize with similar rate, but the result was, only the first core has been fully utilized. Could it be because I/O operation is control by OS only? Thirdly, at what situations should I use multiple threads in a io_service? I increased 50 threads for both io_service in my last experiment setup, and perform the same test. My theory was, when more threads allocated in a io_service , this should help io_service to find a free thread to trigger sockets' complete handler concurrently, therefore, sockets didn't have to wait too long to make the next async read call, and minimize the risk of buffer overflow. The result was completely opposite; the cpu usage has obviously increased, but performance was dramatically decreased because many packet loss was detected. Would it be because of context switching? I thought doesn't matter how many thread were allocated to a io_service, same number of context switching are still required (switching new context from the next complete handler to core to execute after the previous one completed), am I right? B.R Bryan

1 0

[asio][chrono] using steady_timer portably
by Igor R 17 Jan '13

17 Jan '13

Hello, There's some use of asio::steady_timer in my code (1.51): asio::steady_timer timer_; //....... timer_.expires_from_now(boost::chrono::milliseconds(100)); //...... However, the above appears to be non-portable, as under c++11 steady_timer uses std::chrono, while boost::chrono doesn't seem to "forward" its types to std::chrono. I know I can use asio::basic_waitable_timer<boost::chrono::steady_clock> explicitly, but maybe there's some more straightforward solution (eg. boost::chrono configuration)? Thanks.

2 2

Why is boost::format::operator% not declared const?
by Chris Stankevitz 17 Jan '13

17 Jan '13

Hello, I use boost::format to convert a float to a string: void CalledThousandsOfTimesPerSecond(float f) { GetStream() << boost::format("%0.3f") % f << GetSomeOtherContent(); } I normally would deal with something like this by adding a static const variable: void CalledThousandsOfTimesPerSecondFromManyThreads(float f) { static const boost::format Formatter("%0.3f"); GetStream() << Formatter % f << GetSomeOtherContent(); } But this does not work. boost::format::operator% is not declared const. Question 1: Why is boost::format::operator% declared mutable? What is is mutating? Question 2: How do I not spend overhead constructing the same boost::format thousands of times per second? Possible answers to question 2: void CalledThousandsOfTimesPerSecond(float f) { static boost::format Formatter("%0.3f"); // MUTABLE -- this might not be thread safe??? GetStream() << Formatter % f << GetSomeOtherContent(); } void CalledThousandsOfTimesPerSecond(float f) { static const boost::format Formatter1("%0.3f"); boost::format Formatter2(Formatter1); // lame but I guess it works GetStream() << Formatter2 % f << GetSomeOtherContent(); } Thank you, Chris

5 5

Re: [Boost-users] shared memory between 32b and 64b
by Dave Dyer 17 Jan '13

17 Jan '13

Thanks, this pair of definitions gets off the ground. typedef offset_ptr< void , boost::int32_t , boost::uint64_t > my_offset_ptr; typedef basic_managed_shared_memory <char ,rbtree_best_fit<mutex_family, my_offset_ptr> ,iset_index> compat32_shared_memory;

1 0

shared memory between 32b and 64b
by Dave Dyer 16 Jan '13

16 Jan '13

Looked promising, but not quite good enough. I dedined: typedef offset_ptr<class T, std::ptrdiff_t, unsigned long long>my_offset_ptr; typedef basic_managed_shared_memory <char ,rbtree_best_fit<mutex_family, my_offset_ptr> ,iset_index> compat32_shared_memory; in the win64 process I do compat32_shared_memory segment(create_only, SEGMENT_NAME, SEGMENT_SIZE); comm *command = segment.construct<comm>("CommandBlock")(); in the win32 process in do compat32_shared_memory segment(open_only, SEGMENT_NAME); std::pair<comm *,size_t>com = segment.find<comm>("CommandBlock"); the "find" never returns. The code works fine if both processes are win32 or both are win64 Am I on the right track?

2 1