September 2011 - Boost-users

Subclassing "position_iterator"
by Alexander Feldman 04 Sep '11

04 Sep '11

Hi, I have the following question. I want to subclass/implement a new position_iterator that recognizes lines such as: #line 11 "electrical.lcl" and updates accordingly its location. My question is how to do that in the most elegant manner. Shall I copy/paste "position_iterator.hpp" and hack the increment() method? Would you, guys, use a Qi parser to recognize these lines? Maybe there is a better way... Thanks, -- Alex

2 1

Asio example 5 sagmentation fault
by Alessandro Candini 03 Sep '11

03 Sep '11

I'm really interested in exemple 5 of boost asio: http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/tutorial/tuttimer5… I've tried it with boost-1.47.0. I can compile without warnings using: g++ -Wall -pedantic -lboost_thread -lboost_system -o timer5 timer5.cpp but when I launch the executable it gives me a Segmentation fault. Commenting the code I found that the segmentation fault raise at the 3rd line of main: boost::thread t(boost::bind(&boost::asio::io_service::run, &io)); I'm trying on the following machine: Linux office-007 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 29 19:02:55 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Can anyone help me? -- Alessandro Candini MEEO S.r.l. Via Saragat 9 I-44122 Ferrara, Italy Tel: +39 0532 1861501 Fax: +39 0532 1861637 http://www.meeo.it ======================================== "ATTENZIONE:le informazioni contenute in questo messaggio sono da considerarsi confidenziali ed il loro utilizzo è riservato unicamente al destinatario sopra indicato. Chi dovesse ricevere questo messaggio per errore è tenuto ad informare il mittente ed a rimuoverlo definitivamente da ogni supporto elettronico o cartaceo." "WARNING:This message contains confidential and/or proprietary information which may be subject to privilege or immunity and which is intended for use of its addressee only. Should you receive this message in error, you are kindly requested to inform the sender and to definitively remove it from any paper or electronic format."

3 5

[test] Does boost.test support mock objects?
by Jonathon 03 Sep '11

03 Sep '11

Hi, One facility that I really love about Google test is their mock object framework. It facilitates the development of tests/stub objects. Note that this is also delivered in easy mock and mockpp. Does anyone know if Boost.Test offers such a thing? I've looked through the documentation and I couldn't find anything. Thanks, J

2 2

broken link in "New Iterator Concepts"
by Krzysztof Żelechowski 03 Sep '11

03 Sep '11

<URL: http://www.boost.org/ doc/libs/1_47_0/libs/iterator/doc/new-iter-concepts.html > or const T& once issue 200 is resolved <URL: http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/lwg-active.html#200 > Not Found Issue 200 can be found instead at <URL: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200 > I suspect there are more broken links there but I cannot produce a report because the page is invalid, and indeed, so are all pages under doc/libs/1_47_0/libs/iterator/: … href="/favicon.ico" type="image/ico"><link rel="stylesheet" type="text/css" h… (unclosed link element in XHTML mode) Please fix, Chris

3 3

outdated information in "New Iterator Concepts"
by Krzysztof Żelechowski 03 Sep '11

03 Sep '11

<URL: http://www.boost.org/ doc/libs/1_47_0/libs/iterator/doc/new-iter-concepts.html#motivation > "once issue 299 is resolved" However, issue 299 *is* resolved: <URL: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299 > Please update, Chris

2 2

[range] What's the best way to initialize a new container from a range?
by Martin B. 03 Sep '11

03 Sep '11

Hi! Say I have a range R and I want to construct a new container from the range R. Will I always have to repeat the expression yielding the range, or is there a shorter way? Example: std::vector<int> numbers( boost::irange(7, 42).begin(), boost::irange(7, 42).end() ); Note that it's just an example. Is it possible to create a container C from a range expression R in one step? Any helper function for this? cheers, Martin

7 8

[type_traits] deduce argument type of member function with function_traits
by alfC 03 Sep '11

03 Sep '11

Is function_traits the right way to extract the argument type of a member function? In the following example I want to make the last line work. This will be part of larger question, on how to deduce the argument type of operator() for function objects in which operator() is not overloaded. #include <typeinfo> #include <iostream> #include <boost/type_traits/function_traits.hpp> #include <boost/type_traits/remove_pointer.hpp> using namespace std; double dsquare(double l){ return l*l; } int isquare(int l){ return l*l; } struct csquare_impl{ int do(char c) const{ return 'c'; } }; csquare_impl csquare; template<class F> void test(F f){ typename boost::function_traits<typename boost::remove_pointer<F>::type>::arg1_type test_var; cout << typeid(test_var).name() << endl; } int main(){ test(dsquare); // ok, prints "d"(double) test(isquare); // ok, prints "i"(int) test(csquare_impl::do); // not ok, want to print "c"(char) return 0; } Thanks, Alfredo

2 3

Re: [Boost-users] [MultiIndex] Iterator validity when modifying equal_range keys
by Joaquin M Lopez Munoz 03 Sep '11

03 Sep '11

Ovanes Markarian <om_boost <at> keywallet.com> writes: > > On Fri, Sep 2, 2011 at 9:25 PM, Joaquin M Lopez Munoz > <joaquin <at> tid.es> wrote: > > > > Ovanes Markarian <om_boost <at> keywallet.com> writes: > > > > > > entry_data& entries = indexed; //get the view to the MI-Container > > > > What is this supposed to do? Usually you get an index view > > using get(), which you're not using here. > > I thought I am getting an index view here. Isn't it done implicitly... > Why am I suppose to use it than? > The upper statement can be seen as: > > > my_index_container_type::index<named_tag>::type& entries = indexed; > > If I am not suppose to do that this way, why does this code compile? > I know the docs state I should use the > > my_index_container_type::get<...> member, by how is this construct > should be different? In this particular case you're being lucky because the index you're getting is the first one and the whole multi_index_container publicly derives from it. If you tried a different index it wouldn't have worked. In general you shouldn't rely on this trick not even for index #0. > Ok thanks for your help and a great lib! Thanks for using Boost.MultiIndex. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [Boost-users] [MultiIndex] Iterator validity when modifying equal_range keys
by Joaquin M Lopez Munoz 03 Sep '11

03 Sep '11

Ovanes Markarian <om_boost <at> keywallet.com> writes: > > Hello *, > > reading this page What page? > states only that iterator validity is preserved for hashed indices. > I have a multi-index container with ordered_non_unique entries. Iterator validity is preserved for all types of indices. > Is it safe to find a matching range and modify the keys there? In general no, see above. > > Here an example: > > > entry_data& entries = indexed; //get the view to the MI-Container What is this supposed to do? Usually you get an index view using get(), which you're not using here. > > for(iterator_range<entry_data::iterator> r > > = entries.equal_range(boost::make_tuple(false)) > ; !r.empty() > ; r.advance_begin(1) > ) > { > index_data d = r.front(); > > d.masked = true; > entries.replace(r.begin(), d); > } > > > Here updated d.masked field is a first member of the composite key. > What happens if I do the update as shown upon? This fails for two reasons: 1. After entries.replace(...), r.begin() points to a modified element that is out of its original range; hence, r is no longer a proper range (in this particular example, its begin iterator will point beyond its end iterator.) 2. As elements are reordered, some of them can potentially be relocated *before* r.end(), so even if you fix problem #1 you still can end up visiting elements twice. > Would it be more efficient to iterate backwards and do the > update, since than all the elements will not be rearranged? Not really, since other types of similar problems crop up. The following is a possible solution (using iterator pairs rather than ranges since ranges here seem to be more noisy that useful): std::pair<entry_data::iterator,entry_data::iterator> p= entries.equal_range(boost::make_tuple(false)); if(p.first!=p.second){ // non-empty range --(p.second); // solve problem #2 for(;;){ bool end=(p.first==p.second); index_data d=p.first; d.masked=true; entries.replace((p.first)++,d); //++ solves problem #1 if(end)break; } } > Is there also any way to use modify_key with composite index or > are composite index key extractors always read-only? composite_key extractors return an opaque type called composite_key_result that you might esentially trat as read-only: http://www.boost.org/libs/multi_index/doc/reference/key_extraction.html#com… So the short answer is you can't use modify_key with composite keys. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[type traits] Extension to operator detection -> choose your preferred naming
by Frédéric Bron 02 Sep '11

02 Sep '11

It is time to include the type trait extension to the official boost trunk. These traits can detect if you can use a given operator with given arguments. For example: has_plus<double, int>::value is true because the following program compiles without error: double lhs; int rhs; lhs+rhs; We have come to three proposed lists of names (A, B and C): https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames I have included the corresponding names of standard keywords, standard function objects from <functional>, boost Proto and boost Operators. Please give your preference between A, B and C before Sept. 5th. Regards, Frédéric

7 9