- Boost-users - lists.boost.org

[MultiArray, Intrusive] Instantiating a multi_array of intrusive lists as a class member
by Jiri Vyskocil 08 Jan '13

08 Jan '13

Hello, I want to try Boost Intrusive list instead of std::list in a performance and memory critical part of code. I have a Domain object, which contains a boost::multi_array of cells. each cell contains a list of particles std::list<Particle>. This sample code works as expected (std::list): #include <list> #include <iostream> #include <boost/multi_array.hpp> struct Particle { unsigned number; Particle(unsigned n){ number = n; } }; typedef std::list<Particle> ParticleList; typedef boost::multi_array<ParticleList, 3> ParticleArray; class Domain { public: ParticleArray particles; Domain(int x, int y, int z) : particles(boost::extents[x][y][z]) { } }; int main(){ Domain* dom = new Domain(10,10,10); dom->particles[5][5][5].push_back(Particle(1)); std::cout << dom->particles[5][5][5].front().number << std::endl; return 0; } When I try to swap the std::list for an intrusive list, I get a compile error on Domain instantiation. Minimal code leading to the error: #include <boost/intrusive/list.hpp> #include <boost/multi_array.hpp> typedef boost::intrusive::list_base_hook<> BaseHook; struct Particle : BaseHook { unsigned number; }; typedef boost::intrusive::list<Particle> ParticleList; typedef boost::multi_array<ParticleList, 3> ParticleArray; class Domain { public: ParticleArray particles; Domain(int x, int y, int z) : particles(boost::extents[x][y][z]) { } }; int main(){ Domain* dom = new Domain(10,10,10); return 0; } When I try to compile the above code, gcc tells me: In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/bits/stl_tempbuf.h:61:0, from /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/bits/stl_algo.h:64, from /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/algorithm:63, from /usr/include/boost/move/move.hpp:37, from /usr/include/boost/intrusive/detail/has_member_function_callable_with.hpp:22, from /usr/include/boost/intrusive/detail/memory_util.hpp:112, from /usr/include/boost/intrusive/pointer_traits.hpp:26, from /usr/include/boost/intrusive/detail/utilities.hpp:17, from /usr/include/boost/intrusive/list_hook.hpp:19, from /usr/include/boost/intrusive/list.hpp:20, from intrusive.cc:1: /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/bits/stl_construct.h: In function ‘void std::_Construct(_T1*, const _T2&) [with _T1 = boost::intrusive::list<Particle>, _T2 = boost::intrusive::list<Particle>]’: /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/bits/stl_uninitialized.h:189:3: instantiated from ‘static void std::__uninitialized_fill_n<_TrivialValueType>::__uninit_fill_n(_ForwardIterator, _Size, const _Tp&) [with _ForwardIterator = boost::intrusive::list<Particle>*, _Size = long unsigned int, _Tp = boost::intrusive::list<Particle>, bool _TrivialValueType = false]’ /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/bits/stl_uninitialized.h:225:7: instantiated from ‘void std::uninitialized_fill_n(_ForwardIterator, _Size, const _Tp&) [with _ForwardIterator = boost::intrusive::list<Particle>*, _Size = long unsigned int, _Tp = boost::intrusive::list<Particle>]’ /usr/include/boost/multi_array.hpp:477:5: instantiated from ‘void boost::multi_array<T, NumDims, Allocator>::allocate_space() [with T = boost::intrusive::list<Particle>, long unsigned int NumDims = 3ul, Allocator = std::allocator<boost::intrusive::list<Particle> >]’ /usr/include/boost/multi_array.hpp:186:5: instantiated from ‘boost::multi_array<T, NumDims, Allocator>::multi_array(const boost::detail::multi_array::extent_gen<NumDims>&) [with T = boost::intrusive::list<Particle>, long unsigned int NumDims = 3ul, Allocator = std::allocator<boost::intrusive::list<Particle> >]’ intrusive.cc:18:49: instantiated from here /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/bits/stl_construct.h:84:7: error: passing ‘const boost::intrusive::list<Particle>’ as ‘this’ argument of ‘boost::intrusive::list<T, O1, O2, O3>::operator boost::rv<boost::intrusive::list<T, O1, O2, O3> >&() [with T = Particle, O1 = boost::intrusive::none, O2 = boost::intrusive::none, O3 = boost::intrusive::none]’ discards qualifiers [-fpermissive] This is just a minimal sample code to trigger an error. In the actual code, both Domain and Particle objects are more complicated. The last line of error output is sligtly different: /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/bits/stl_construct.h:84:7: error: no matching function for call to ‘boost::intrusive::list<Particle>::list(const boost::intrusive::list<Particle>&)’ followed by a note with a list of candidate functions. If I define the multi_array so that it contains pointers to ParticleArray, i.e.: typedef boost::multi_array<ParticleList*, 3> ParticleArray; there seems to be no benefit over the std::list approach, since I have to hold the additional pointer. In a test simulation, this variant eats about 10% more RAM, which is of concern in our situation. Any ideas how to replace std::list with boost::intrusive::list in a multi_array in a way which wouldn't consume more memory than the std::list approach? (I would want to see if it also brings the much needed performance benefit) Jiri Vyskocil

2 5

[Iterator] filter_iterator over greedy?
by Robert Jones 07 Jan '13

07 Jan '13

Hi Folks, Somewhat to my surprise this code, simply creating a filter_iterator, evaluates the predicate until an element satisfying the predicate is found. This seems wrong to me. Shouldn't evaluation of the predicate be delayed until the filter_iterator is dereferenced? Thx, Rob. #include <iostream> #include <boost/range.hpp> #include <boost/iterator/filter_iterator.hpp> bool predicate( int i ) { std::cout << "predicate(" << i << ")" << std::endl; return true; } int main( ) { int array[] = { 0, 1 }; boost::make_filter_iterator( predicate, boost::begin( array ), boost::end( array ) ); } > [Run] predicate(0) >

2 1

Using OvenToBoost 'taken'.
by Robert Jones 07 Jan '13

07 Jan '13

Hi Folks This question is about using the OvenToBoost port, not currently part of Boost, but likely to be soon, I understand. The code below evaluates the predicate for the first and second elements of the array. The evaluation of the second element seems to me to be unnecessary and wrong, since the 'taken' adaptor knows the range is ended after the first element is taken. Thoughts? Thx, Rob. #include <boost/range/adaptor/filtered.hpp> #include <boost/range/adaptor/taken.hpp> #include <boost/range/algorithm/for_each.hpp> #include <iostream> bool predicate( int i ) { std::cout << "predicate(" << i << ")" << std::endl; return true; } void doNothing( int ) { } int main( ) { int array[ ] = { 0, 1, 2, 3, 4, 5 }; for_each( array | boost::adaptors::filtered( predicate ) | boost::adaptors::taken( 1 ), doNothing ); }

2 2

[Property Tree] Complexity of find and get methods
by Elizabeta 07 Jan '13

07 Jan '13

Hi I want to know the complexity of boost property tree find and get methods. I tried the following link http://www.boost.org/doc/libs/1_41_0/doc/html/boost/property_tree/basic_ptr… but it seems that the complexity is not specified. Also can find function accept string paths or it just finds immediate childs? Thank you

2 1

Problem finally found!
by Gonzalo Garramuno 06 Jan '13

06 Jan '13

My problem was that acceptor_ was called twice and two sessions were created. The first session was used properly while the second session missed the socket setup. class server { public: server(boost::asio::io_service& io_service, const tcp::endpoint& listen_endpoint, mrv::ViewerUI* v) : io_service_(io_service), acceptor_(io_service, listen_endpoint), ui_( v ) { start_accept(); } void start_accept() { tcp_session_ptr new_session( boost::make_shared<tcp_session>( boost::ref( io_service_ ), boost::ref(ui_) ) ); std::cerr << "******** TCP SESSION " << new_session << std::endl; acceptor_.async_accept(new_session->socket(), boost::bind(&server::handle_accept, this, new_session, _1)); } void handle_accept(tcp_session_ptr session, const boost::system::error_code& ec) { if (!ec) { session->start(); } start_accept(); // BAD } Changed to: void handle_accept(tcp_session_ptr session, const boost::system::error_code& ec) { if (!ec) { session->start(); } else { start_accept(); } } I still don't know why this is so and the problem is not fully resolved, as only the server change in the timeline works only once, but at least the server now works.

3 3

[interprocess] (OS X) waiting on condition variable = CPU 100% + fans running loud
by Francisco Lopes 06 Jan '13

06 Jan '13

Hi, I was implementing a kind of server using shared memory. The server should keep idle, waiting for a request and I do this by waiting on a condition variable, of course. I then noticed my fans running high when I let the server waiting a little longer while testing and discovered this happens simply because of some busy loop implementation for condition waiting. Is there any reason for that? Given the interprocess library age, no way for implementing a non-busy interprocess condition variable waiting is available? https://svn.boost.org/trac/boost/ticket/6108 Regards, Francisco Lopes

2 1

MPL vs. Proto for EDSL dev?
by Chris Russell 05 Jan '13

05 Jan '13

Hello, all. I'm reading the MPL book (again) and tinkering with some ideas for a new library for building complex FSM hierarchies [1]. I've got a minimal runtime library written that codifies the important concepts but now want to try to make it a native C++ EDSL and am wondering if it makes more sense to concentrate on MPL, Proto (or both)? For pure education on the subject of C++ template metaprogramming the MPL and the amazing Abrahams/Gurtovoy book seems like the right starting place but would appreciate any advice you folks are willing to share with me. Thanks, Chris [1] I am aware of other FSM libs (e.g. StateChart, MSM) and likely some of what I'm planning is redundant. That's okay: my goal is to gain deeper understanding of C++ template metaprogramming by working through a non-trivial problem.

2 2

boost-mpi assertion during recv fails
by Kyle Joseph Berger 04 Jan '13

04 Jan '13

Hello, I am using boost-mpi and I am getting an error that I am having a hard time figuring out. I am using a recv call and an assertion in the boost code fails: void boost::mpi::binary_buffer_iprimitive::load_impl(void *, int): Assertion `position+l<=static_cast<int>(buffer_.size())' This is from the file binary_bffer_iprimitive.hpp located in boost/mpi/detail/. This does not occur the first time I am receiving so I know it's not a general error with every send/recv call I make. I think this assertion is checking whether the buffer is large enough to accommodate the data being received, but I'm not even sure about that. If that is the case, what could cause the buffer to not be large enough? Shouldn't that be taken care of by the underlying boost? Thanks, Kyle

2 2

[Locale] Security bug announcement - UTF-8 validation
by Artyom Beilis 04 Jan '13

04 Jan '13

Hello, Boost.Locale library in Boost 1.48 to 1.52 including has a security flow. boost::locale::utf::utf_traits accepted some invalid UTF-8 sequences. Applications that used these functions for UTF-8 input validation could expose themself to security threats as invalid UTF-8 sequece would be considered as valid. This bug is fixed in upcoming Boost 1.53. For more details see: https://svn.boost.org/trac/boost/ticket/7743 Users who can't upgrade to the latest versions may apply the following patch to fix the problem. http://cppcms.com/files/locale/boost_locale_utf.patch Regards, Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

1 0

How to convert shared_ptr to pointer?
by young 03 Jan '13

03 Jan '13

I have shared_ptr<int> variable. I need to pass a int* pointer to a function call. How to pass shared_ptr<int> as int *? -- View this message in context: http://boost.2283326.n4.nabble.com/How-to-convert-shared-ptr-to-pointer-tp4… Sent from the Boost - Users mailing list archive at Nabble.com.

5 4