- Boost-users - lists.boost.org

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 03 Sep '11

03 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

64bit boost::regex link error
by Lloyd 02 Sep '11

02 Sep '11

Hi, I am trying to port a 32bit application built on 32bit windows to 64bit. We are using boost::regex library. We have successfully built 64 bit version of boost. When we try to link our application with boost::regex we get the following error. What could be the reason? We are using MS Windows 7 64bit, MS Visual studio 2010, and boost 1.46.1 This is the how we built boost # bjam --build-type=minimal --with-regex --address-model=64 This is the error reported. myfile.obj : error LNK2001: unresolved external symbol "private: class boost::basic_regex<char,struct boost::regex_traits<char,class boost::w32_regex_traits<char> > > & __cdecl boost::basic_regex<char,struct boost::regex_traits<char,class boost::w32_regex_traits<char> > >::do_assign(char const *,char const *,unsigned int)" (?do_assign@?$basic_regex@DU?$regex_traits@DV?$w32_regex_traits@D@boost@@@boost@@@boost@@AEAAAEAV12@PEBD0I@Z) myfile.obj : error LNK2001: unresolved external symbol "private: void __cdecl boost::re_detail::perl_matcher<char const *,class std::allocator<struct boost::sub_match<char const *> >,struct boost::regex_traits<char,class boost::w32_regex_traits<char> > >::construct_init(class boost::basic_regex<char,struct boost::regex_traits<char,class boost::w32_regex_traits<char> > > const &,enum boost::regex_constants::_match_flags)" (?construct_init@?$perl_matcher@PEBDV?$allocator@U?$sub_match@PEBD@boost@@@std@@U?$regex_traits@DV?$w32_regex_traits@D@boost@@@boost@@@re_detail@boost@@AEAAXAEBV?$basic_regex@DU?$regex_traits@DV?$w32_regex_traits@D@boost@@@boost@@@3@W4_match_flags@regex_constants@3@@Z) myfile.obj : error LNK2001: unresolved external symbol "public: bool __cdecl boost::re_detail::perl_matcher<char const *,class std::allocator<struct boost::sub_match<char const *> >,struct boost::regex_traits<char,class boost::w32_regex_traits<char> > >::find(void)" (?find@?$perl_matcher@PEBDV?$allocator@U?$sub_match@PEBD@boost@@@std@@U?$regex_traits@DV?$w32_regex_traits@D@boost@@@boost@@@re_detail@boost@@QEAA_NXZ) Thanks, Lloyd

2 1

[serialization] can't serialize to derived archive via base class ptr
by frankg 02 Sep '11

02 Sep '11

Hi, I try to serialize a derived object by its base class pointer to an archive I derived from xml_oarchive_impl exactly the same way as it is documented in the example code here: http://www.boost.org/doc/libs/1_47_0/libs/serialization/example/log_archive… http://www.boost.org/doc/libs/1_47_0/libs/serialization/example/log_archive… However, when I start the program (to output to my derived archive) I get the assertion (“BOOST_ASSERT(false)”) in the following method in “basic_serializer_map.cpp” (I checked with the debugger (VS2010) and found the m_map.size() is 0). BOOST_ARCHIVE_DECL(const basic_serializer *) basic_serializer_map::find( const boost::serialization::extended_type_info & eti ) const { const basic_serializer_arg bs(eti); map_type::const_iterator it; it = m_map.find(& bs); if(it == m_map.end()){ BOOST_ASSERT(false); return 0; } return *it; } If I use the DERIVED class pointer it works fine with my own derived archive. If I use a BASE class pointer and use the ORIGINAL xml_oarchive it works fine too. Only when I combine both (using my own derived archive AND try to serialize through a base class pointer) it fails with the assertion. Here is an excerpt of my code and 3 cases, where the first and second work fine and the third asserts: THIS WORKS FINE: int _tmain(int argc, _TCHAR* argv[]) { Base* bptr = new Derived; // using base class ptr boost::archive::xml_oarchive oa(std::cout, boost::archive::no_header); // using original archive from boost::serialization oa & BOOST_SERIALIZATION_NVP(bptr); return 0; } THIS WORKS FINE TOO: int _tmain(int argc, _TCHAR* argv[]) { Derived* dptr = new Derived; // using derived class ptr log_archive oa(std::cout, boost::archive::no_header); // using derived archive oa & BOOST_SERIALIZATION_NVP(dptr); return 0; } THIS ASSERTS: int _tmain(int argc, _TCHAR* argv[]) { Base* bptr = new Derived; // using base class ptr log_archive oa(std::cout, boost::archive::no_header); // using derived archive oa & BOOST_SERIALIZATION_NVP(bptr); return 0; } Is there something I can do to get my derived archive correctly working or doesn’t support the boost::serialization lib the combination of deriving archives and serializing via base class pointers at the same time? One more hint: using the debugger I saw that the m_map member in "basic_serializer_map.hpp" is statically initialized before main() is started. Some information for all my derived classes which contain serialization-methods where inserted into m_map. So m_map isn't actually empty but it seems to be a different object than the one where m_map has been initialized. Cheers, Frank -- View this message in context: http://boost.2283326.n4.nabble.com/serialization-can-t-serialize-to-derived… Sent from the Boost - Users mailing list archive at Nabble.com.

2 1

[MultiIndex] Iterator validity when modifying equal_range keys
by Ovanes Markarian 02 Sep '11

02 Sep '11

Hello *, reading this page states only that iterator validity is preserved for hashed indices. I have a multi-index container with ordered_non_unique entries. Is it safe to find a matching range and modify the keys there? Here an example: entry_data& entries = indexed; //get the view to the MI-Container 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? Would it be more efficient to iterate backwards and do the update, since than all the elements will not be rearranged? Is there also any way to use modify_key with composite index or are composite index key extractors always read-only? With Kind Regards, Ovanes

1 0

Re: [Boost-users] How to detect thread kill?
by Samvel Khalatyan 02 Sep '11

02 Sep '11

Thank you, Chris. On Fri, Sep 2, 2011 at 10:43 AM, Samvel Khalatyan <samvel(a)fnal.gov> wrote: > Thank you, Chris. > > > On Fri, Sep 2, 2011 at 10:36 AM, Chris Cleeland <chris.cleeland(a)gmail.com>wrote: > >> On Fri, Sep 2, 2011 at 10:24 AM, Samvel Khalatyan >> <samvel.khalatyan(a)gmail.com> wrote: >> > I guess you are right: the whole process is killed with all thread from >> > Linux command line. I suppose, there is no way to kill single thread. >> >> Not from the command line. pthread_kill() can direct a signal to a >> specific thread, but only from within the process that hosts the >> thread. >> >> The "pthreads primer" and "Programming Pthreads" books have some >> reasonable discussions on mixing signals and threads. Beware that >> they don't mix well. >> _______________________________________________ >> Boost-users mailing list >> Boost-users(a)lists.boost.org >> http://lists.boost.org/mailman/listinfo.cgi/boost-users >> > >

1 0

How to detect thread kill?
by Samvel Khalatyan 02 Sep '11

02 Sep '11

Hi, There is a number of standard ways to interrupt thread from within an application with library tools. However, is there a way to detect if one of the running threads was killed with system tools and thread is not available any more? thanks, Samvel.

3 7

[MultiIndex] cryptic gcc error
by Ovanes Markarian 02 Sep '11

02 Sep '11

Hello *, I try to use a multi_index container with a composite key. The container is defined as follows: struct index_data { entry_header header; //has various public fields one of them is timestamp_ fs::entry entry; bool masked; }; typedef size_t timestamp_t; //in reallity this type is a class, but the error can be reproduced with this typedef as well timestamp_t const& timestamp(index_data const& data) { return data.header.timestamp_; } bool mask_state(index_data const& data) { return data.masked; } struct entry_data_tag {}; typedef mi::multi_index_container < index_data, mi::indexed_by < mi::ordered_non_unique < mi::tag<entry_data_tag> , mi::composite_key < mi::global_fun<index_data const&, bool, &mask_state> //this could be a direct member reference, but I intially used fusion::map and reduced the problem to minimum , mi::global_fun<index_data const&, timestamp_t const&, &timestamp> > > > > entry_index; typedef entry_index::index<entry_data_tag>::type entry_data; void mask_all() { using namespace boost::lambda; entry_data& entries = pimpl_->indexed; entries.find(boost::make_tuple(false)); //!!!! this line results in an error novel by gcc 4.3 } The error description is: multi_index/composite_key.hpp:638: error: no match for 'operator*' in '*x' Does anyone have some suggestions why that happens? With Kind Regards, Ovanes

2 3

[serialization] Export macro doesnt work
by Jari 02 Sep '11

02 Sep '11

Hi I was trying to use BOOST_CLASS_EXPORT for all my classes in order to save them but I always got unregistered class error. So I used oa.register_type<object>(); for the class that was causing the error and problem solved. But why doesnt the BOOST_CLASS_EXPORT macro work? Why I need to use oa.register_type<object>(); ? Im using Boost 1.46.1 Thanks

3 10