March 2006 - Boost-users - lists.preview.boost.org

[unit-test] Can'f find boost::unit_test::register_exception_translator
by Gustavo Ribeiro Alves 17 Mar '06

17 Mar '06

I'm trying to register some user exceptions on the unit_test framework so I did the following: #include <boost/test/unit_test.hpp> using boost::unit_test::register_exception_translator; . . . void translate_InvalidInterval(const Interval::InvalidInterval& e) { } void translate_NotIntercept(const Interval::NotIntercept& e) { } interval_test_suite::interval_test_suite() : test_suite ("interval_test_suite") { boost::unit_test::register_exception_translator<Interval::InvalidInterval> (translate_InvalidInterval); boost::unit_test::register_exception_translator< Interval::NotIntercept> (translate_NotIntercept); . . . } I get the following compile error: error: 'boost::unit_test::register_exception_translator' has not been declared I tried to grep all .hpp files on /boost/test to find if some of them have this function. The only one (execution_monitor.hpp) I found has it as part of a class. I was expecting it as a template function in the framework. So, how what do I have to include to make this work?

2 1

signals disconnect based on equivalent slots
by James Burgess 17 Mar '06

17 Mar '06

This works on gcc3.3 and gcc4.0 (OSX) but doesn't compile on vc8.0 I'm wondering whether it should and I've just messed up somewhere installing boost 1.33 or vc8 (VS 2005). I noted that the regression test does not perform this form of disconnect, is that the manual telling me this isn't supported? I get a very similar error if I try a functor (using bind) rather than example below ~ "can't convert to 'const int'". There's some comments in signal_template.hpp that indicate vc 6.0 and 7.0 have problems with this, maybe that #ifdef needs to include vc8? cheers, - James. #include <iostream> #include <boost/signals.hpp> void rfun() { std::cerr << "Hello World\n"; } int _tmain(int argc, char* argv[]) { boost::signal<void()> sig; sig.connect(&rfun); sig.disconnect(&rfun); return 0; } 1>------ Build started: Project: testsignals, Configuration: Debug Win32 ------ 1>Compiling... 1>testsignals.cpp 1>i:\testsignals\testsignals.cpp(19) : error C2664: 'boost::signal0<R,Combiner,Group,GroupCompare,SlotFunction>::disconnect' : cannot convert parameter 1 from 'void (__cdecl *)(void)' to 'const int &' 1> with 1> [ 1> R=void, 1> Combiner=boost::last_value<void>, 1> Group=int, 1> GroupCompare=std::less<int>, 1> SlotFunction=boost::function<void (void)> 1> ] 1> Reason: cannot convert from 'void (__cdecl *)(void)' to 'const int' 1> There is no context in which this conversion is possible

2 1

[optional] mixed (optional<T>, T)-operator== missing by design?
by Marc Mutz 17 Mar '06

17 Mar '06

Hi, In 1.33.1, comparing an optional<T> to it's T fails, since although T implicitly converts to optional<T>, op== being templated, implicit conversions are not considered. Is this by design? If so, what's the rationale for this? I repeatedly find myself in the need to compare an optional<T> member to a passed in T, e.g. in a setT( const T & ), in order to check for a no-op operation and suppress notifications in this case, e.g.: class Foo { boost::optional<T> mT; boost::signal< void(const optional<T>&) > tChangedSignal; void setT( const T & t ) { if ( t == mT ) return; mT = t; tChangedSignal( mT ); // mark cached values dirty, etc, etc... } }; -- Marc Mutz -- marc(a)klaralvdalens-datakonsult.se, mutz(a)kde.org Klarälvdalens Datakonsult AB, Platform-independent software solutions

2 2

Re: [Boost-users] Are Boost.Multi_Index and Boost.Format Planned for64-bitPortability?
by Wu Yinghui, Freddie 17 Mar '06

17 Mar '06

> Hello Freddie, > > As for Boost.MultiIndex, I can confirm the lib does work in 64-bit > environments (for instance, Linux PPC64, Tru64) and must also work > for Win64, although I've never had actual reports about this latter > platform (if you've got access to Win64, you might want to try and > tell back.) With respect to /Wp64 warnings, they are of two > kinds: > > * C4312/C4311, conversions between differently sized types: this > is a case of /Wp64 being too dumb in its analysis of the type > boost::multi_index::detail::uintptr_type; this type is defined with > some metaprogramming machinery to be some integral type > with the same size as void*. So, it is unsigned int in Win32 and > unsigned long long in Win64. But /Wp64 sees it defined as > unsigned int, hence the warning. It is as if you had: > > #ifdef _WIN64 > typedef unsigned int integral_type; > #else > typedef unsigned long long integral_type; > #endif > void *p; > integral_type x=(integral_type)p; > > /Wp64 is not able to see that integral_type will be > defined as unsigned long long in Win64, and emits a C4311. Thanks for your helpful explanation. Since this types of warnings flood the compiler output, which very difficult for us to notice other more valuable warnings. Guess we'll need to figure out some way to "hide" the stupid compiler behaviour? > * Complains about some internal node classes not being > constructable or about their automatic default constructors > being impossible to generate. I don't see what this has to do > with 64-bit portability; in any case, the compiler is right about > the analysis, but not about the consequences: these classes > are in effect never default constructed, their lifetime being > managed through an allocator interface. This is just an > overzealous warning. Hmm... In this case, I guess I'd just try to add some default constructors for these classes without implementing them. That way, I can at least get away with this type of warnings. > So, Boost.MultiIndex must work in Win64, the best way to > check this out is to actually try. I do not have the 64-bit machine with me yet. But I'll report back later once I actually have the chance to try it out. > As for Boost.Format, I cannot say cause I'm not the maintainer, > but in any case it seems to work on other 64-bit environments > as per the regression tests, and potential 64-bit problems > should be easy to tackle. Thanks for your insights! > Joaqu?n M L?pez Mu?oz > Telef?nica, Investigaci?n y Desarrollo > Cheers, Freddie -- Wu Yinghui, Freddie Research & Development Software Engineer Volume Interactions Pte Ltd 1 Kim Seng Promenade, #12-01 Great World City East Tower Singapore 237994 Tel: +65 62226962 (Ext 216) Fax: +65 62226215 Email: yhwu(a)volumeinteractions.com URL: http://www.volumeinteractions.com Important: This message is intended for the recipient(s) addressed above. It contains privileged and confidential information. If you are not the intended recipient, please notify the sender immediately by replying to this message and then delete it from your system. You must not read, copy, use, or disseminate this communication in any form. Thank you.

2 1

[iostreams] - device ready for non-blocking operations?
by Oliver.Kowalke＠infineon.com 17 Mar '06

17 Mar '06

Hello, is a device, which read and write member-functions could be non-blocking, per default ready for non-blocking operations - or what do I have to do in order to make it properly working with iostreams? Regards, Oliver

1 0

[serialization] My implementation of serialization of STL iterators.
by Carlo Wood 17 Mar '06

17 Mar '06

I succeeded in writing code that successfully serializes my data structures, which contain a LOT a iterators, and even vectors of iterators. However, the end result turned out to be extremely slow (it takes several minutes), due to some inefficiency in boost::serialization (it should be possible to serialize this in a few seconds). I didn't investigate why boost::serialization becomes so slow, but I suppose it is caused by the fact that as a result of how things are serialized, the structure written to file is several thousands of levels deep (meaning, that in the XML file the indentation of the output is also many thousands of TAB's deep). I'm going to approach my problem of serialization in a different way now - making a copy of the data structure, such that the result can be serialized without needing to serialize iterators. Nevertheless, I don't want to keep my solution for the iterators from others; so below follows a brief overview of what I made. An average serialize() function looks as follows: template<class Archive> void Data::serialize(Archive& ar, unsigned int const) { ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(BaseClass); ar & BOOST_SERIALIZATION_NVP(M_variable); ar & BOOST_SERIALIZATION_ITERATOR_NVP(container, M_iterator); ar & BOOST_SERIALIZATION_ITERATOR_NVP(container, M_vector_of_iterators); } where BOOST_SERIALIZATION_ITERATOR_NVP is my invention ;). 'container' has to be the container that the iterator(s) point at. In the case of a vector of iterators, that is the container that the iterators point at, not the vector. Ie, M_iterator could of type std::set<FooBar>::iterator, then container is the std::set<FooBar> container, and M_vector_of_iterators would be of type std::vector<std::set<FooBar>::iterator>. Both, the container type (std::set<FooBar>) as well as the type of it's elements need to be tracked; hence, the above would need: BOOST_CLASS_TRACKING(FooBar, boost::serialization::track_always); BOOST_CLASS_TRACKING(std::set<FooBar>, boost::serialization::track_always); This would then first serialize the container (if not already done) and then serialize the element that the iterator points to (if not already done). I defined BOOST_SERIALIZATION_ITERATOR_NVP as follows: // This macro generates the name string (from 'name'). #define BOOST_SERIALIZATION_ITERATOR_NVP(container, name) \ serialization_iterator_nvp(container, BOOST_PP_STRINGIZE(name), name) where serialization_iterator_nvp is an heavily overload, inline template function: template<typename Container> inline boost::serialization::nvp<IteratorWrapper<Container, typename Container::iterator> > serialization_iterator_nvp(Container& container, char const* name, typename Container::iterator const& t) { IteratorWrapper<Container, typename Container::iterator> tmp(container, const_cast<typename Container::iterator&>(t)); return boost::serialization::nvp<IteratorWrapper<Container, typename Container::iterator> >(name, tmp); } template<typename Container> inline boost::serialization::nvp<IteratorWrapper<Container, typename Container::const_iterator> > serialization_iterator_nvp(Container& container, char const* name, typename Container::const_iterator const& t) { IteratorWrapper<Container, typename Container::const_iterator> tmp(container, const_cast<typename Container::const_iterator&>(t)); return boost::serialization::nvp<IteratorWrapper<Container, typename Container::const_iterator> >(name, tmp); } // Specialization for std::set, because for that container, the iterator and const_iterator are the same type! template<typename T> inline boost::serialization::nvp<IteratorWrapper<std::set<T>, typename std::set<T>::const_iterator> > serialization_iterator_nvp(std::set<T>& container, char const* name, typename std::set<T>::const_iterator const& t) { IteratorWrapper<std::set<T>, typename std::set<T>::const_iterator> tmp(container, const_cast<typename std::set<T>::const_iterator&>(t)); return boost::serialization::nvp<IteratorWrapper<std::set<T>, typename std::set<T>::const_iterator> >(name, tmp); } And in order for BOOST_SERIALIZATION_ITERATOR_NVP to also deal with vectors of iterators: template<typename Container> inline boost::serialization::nvp<VectorIteratorWrapper<Container, typename Container::iterator> > serialization_iterator_nvp(Container& container, char const* name, std::vector<typename Container::iterator> const& v) { VectorIteratorWrapper<Container, typename Container::iterator> tmp(container, const_cast<std::vector<typename Container::iterator>&>(v)); return boost::serialization::nvp<VectorIteratorWrapper<Container, typename Container::iterator> >(name, tmp); } template<typename Container> inline boost::serialization::nvp<VectorIteratorWrapper<Container, typename Container::const_iterator> > serialization_iterator_nvp(Container& container, char const* name, std::vector<typename Container::const_iterator> const& v) { VectorIteratorWrapper<Container, typename Container::const_iterator> tmp(container, const_cast<std::vector<typename Container::const_iterator>&>(v)); return boost::serialization::nvp<VectorIteratorWrapper<Container, typename Container::const_iterator> >(name, tmp); } // Specialization for std::set, because for that container, the iterator and const_iterator are the same type! template<typename T> inline boost::serialization::nvp<VectorIteratorWrapper<std::set<T>, typename std::set<T>::const_iterator> > serialization_iterator_nvp(std::set<T>& container, char const* name, std::vector<typename std::set<T>::const_iterator> const& v) { VectorIteratorWrapper<std::set<T>, typename std::set<T>::const_iterator> tmp(container, const_cast<std::vector<typename std::set<T>::const_iterator>&>(v)); return boost::serialization::nvp<VectorIteratorWrapper<std::set<T>, typename std::set<T>::const_iterator> >(name, tmp); } This uses two template class wrappers (which are declared before these functions in my file): IteratorWrapper and VectorIteratorWrapper. Their definitions are as follows: // A wrapper for iterators. template<class Container, typename Iterator> class IteratorWrapper { public: IteratorWrapper(Container& container, Iterator& iter) : M_container(container), M_iter(iter) { } private: Container& M_container; // The container. Iterator& M_iter; // The actual iterator. public: template<class Archive> void save(Archive& ar, unsigned int const) const { BOOST_STATIC_ASSERT(boost::serialization::tracking_level<Container>::type::value == boost::serialization::track_always); BOOST_STATIC_ASSERT(boost::serialization::tracking_level<typename Container::value_type>::type::value == boost::serialization::track_always); ar << boost::serialization::make_nvp("container", M_container); bool is_end = M_iter == M_container.end(); ar << boost::serialization::make_nvp("end", is_end); if (!is_end) ar << boost::serialization::make_nvp("element", *M_iter); } template<class Archive> void load(Archive& ar, unsigned int const) { ar >> boost::serialization::make_nvp("container", M_container); bool is_end; ar >> boost::serialization::make_nvp("end", is_end); if (!is_end) { typename Container::value_type* tmp_value; ar >> boost::serialization::make_nvp("element", tmp_value); } else M_iter = M_container.end(); } BOOST_SERIALIZATION_SPLIT_MEMBER() }; // A wrapper for a vector of iterators. template<class Container, typename Iterator> class VectorIteratorWrapper { public: VectorIteratorWrapper(Container& container, std::vector<Iterator>& iter) : M_container(container), M_vec(iter) { } private: Container& M_container; // The container. std::vector<Iterator>& M_vec; // The actual vector of iterators. public: template<class Archive> void save(Archive& ar, unsigned int const) const { BOOST_STATIC_ASSERT(boost::serialization::tracking_level<Container>::type::value == boost::serialization::track_always); BOOST_STATIC_ASSERT(boost::serialization::tracking_level<typename Container::value_type>::type::value == boost::serialization::track_always); int count = M_vec.size(); ar << BOOST_SERIALIZATION_NVP(count); for (typename std::vector<Iterator>::const_iterator iter = M_vec.begin(); iter != M_vec.end(); ++iter) { IteratorWrapper<Container, Iterator> iter_functor(M_container, const_cast<Iterator&>(*iter)); ar << boost::serialization::make_nvp("item", iter_functor); } } template<class Archive> void load(Archive& ar, unsigned int const) { int count; ar >> BOOST_SERIALIZATION_NVP(count); while(count--) { Iterator tmp_iter; IteratorWrapper<Container, Iterator> iter_functor(M_container, tmp_iter); ar >> boost::serialization::make_nvp("item", iter_functor); M_vec.push_back(tmp_iter); } } BOOST_SERIALIZATION_SPLIT_MEMBER() }; In both cases, the assertions make sure you didn't forget the two BOOST_CLASS_TRACKING lines. Have fun with it, Carlo Wood <carlo(a)alinoe.com> PS I didn't test the load() functions, but the resulting archive (I used xml) looked correct, thus, the serialization works.

1 0

Re: [Boost-users] boost::multi_index_container::erase very slow on FreeBSD 6.0
by JOAQUIN LOPEZ MU?Z 16 Mar '06

16 Mar '06

----- Mensaje original ----- De: bert hubert <bert.hubert(a)netherlabs.nl> Fecha: Jueves, Marzo 16, 2006 10:59 pm Asunto: [Boost-users] boost::multi_index_container::erase very slow on FreeBSD 6.0 > Ok, regarding my previous message, I've now boiled down the > problem of > quadratically slower erases to something that does happen on > FreeBSD 6.0 and > doesn't happen on my Linux machines. > > The problem may be due to: > 1) boost::multi_index container (highly unlikely) > 2) g++ allocator > 3) FreeBSD libc, if the g++ allocator relies on it > 4) FreeBSD kernel > > And I don't even know where to start. > Hello Bert, I've just compiled and run your benchmark in Windows (with minor modifications to substitute for Unix-specific timing functions) and the behavior is O(N). I'm sorry I can't be more helpful, the following is a series of steps you can use to gain more insight into the problem: 1) Use a multimap instead of the multi_index_container. Double the number of elements to compensate for the fact that the multi-index container takes more memory per element (as it has two indices.) 2) Undo 1) and try running the 100..5000 loop in reverse order 5000..100. What do you get? If the quadratic behavior shows as we approach n=100 (the opposite of the original benchmark) I would tend to think the issue has to do with memory fragmentation. 3) Try a pool allocator like for instance boost::fast_pool_allocator: http://boost.org/libs/pool/doc/interfaces/pool_alloc.html I hope some of this can shed some light. Joaquín M López Muñoz Telefónica, Investigsción y Desarrollo

2 1

Re: [Boost-users] [multi_index] modify_range?
by JOAQUIN LOPEZ MU?Z 16 Mar '06

16 Mar '06

----- Mensaje original ----- De: Jeff Flinn <TriumphSprint2000(a)hotmail.com> Fecha: Jueves, Marzo 16, 2006 11:09 pm Asunto: Re: [Boost-users] [multi_index] modify_range? > Joaquín Mª López Muñoz wrote: > > So wouldn't the only use of modify_unstable_range be for modifying > keys and > indirect members? So only a single modify_unstable_range calling > .modify_key > would suffice? Just thinking out loud here, until I have access to > the docs. I'm not sure I'm making my point. There are two orthogonal issues to consider here: 1 Whether you are modyfing whole elements (A) or keys (B). 2 Whether the modification is "stable" (1) or not (2). The four combinations are actual possibilities: A1: modify_range A2: modify_unstable_range B1: modify_key_range B2: modify_key_unstable_range where B1 and B2 (which are not given in my previous snippet) are written exactly as A1 and A2, respectively, except that where it read .modify(...) you've got to write .modify_key(...). "Stability" is not dependant on whether you're modifying elements or keys: you can get stable and unstable range modifications both ways. What defines a stable range modification of the form modify[_key]_range(i,first,last,mod) is that, after modifying an element pointed to by iterator it, the resulting repositioning does not lie inside [++it,last), i.e. we're sure we won't visit the element again. You can see in my previous snippets examples of stable and unstable range modifications. > > Thanks for your library and your help. :) > > Jeff You're welcome, thank you for using the Boost.MultiIndex. Joaquín M López Muñoz Telefónica, Inevstigación y Desarrollo _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

purge_memory of fast_pool_allocator's singleton pool
by Michael Fawcett 16 Mar '06

16 Mar '06

Is there a way to purge the memory of the underlying singleton_pool used by a specific fast_pool_allocator? For example: typedef boost::fast_pool_allocator < std::pair<const int, astar_node *>, boost::default_user_allocator_new_delete, boost::details::pool::null_mutex > my_allocator; typedef std::map<int, astar_node *, std::less<int>, my_allocator> MyMap; // ...do lots of allocations // I don't care about destructors being called, just release ALL memory if (boost::singleton_pool < boost::fast_pool_allocator_tag, sizeof(my_allocator::value_type), my_allocator::user_allocator, my_allocator::mutex, my_allocator::next_size >::purge_memory() == false) { std::cout << "Failed to purge the fast_pool!!" << std::endl; } This always prints the error message for me. I suspect it has something to do with map's allocator rebinding to allocate map nodes, but I'm not sure how to solve this. Any help would be appreciated.

1 0

Re: [Boost-users] [multi_index] modify_range?
by JOAQUIN LOPEZ MU?Z 16 Mar '06

16 Mar '06

Jeff Flinn wrote: > It would be nice to have a modify_range/modify_key_range that would apply a > function object to each deref'd iterator in the range. Since the multi_index > iterator derefences to a const value_type&, one can not use std::for_each in > particular to apply modifications. Or am I missing something. Hello Jeff, I think it is possible to have what you want without requiring that a new facility be provided by Boost.MultiIndex itself. For you can write: template<typename Index,typename Modifier> void modify_range( Index& i,typename Index::iterator first,typename Index::iterator last, Modifier mod) { while(first!=last)i.modify(first++,mod); } and use it as in the following example: struct adder { adder(int n):n(n){} void operator()(int& x)const{x+=n;} private: int n; }; typedef multi_index_container< int, indexed_by< ordered_non_unique<boost::multi_index::identity<int> > > > multi_index_type; multi_index_type m; for(int i=0;i<10;++i)m.insert(i); modify_range(m,m.begin(),m.end(),adder(-2)); or with Boost.Lambda if you prefer: modify_range(m,m.begin(),m.end(),_1-=2); There is a problem, though: consider the following: // buggy call ro modify_range modify_range(m,m.begin(),m.end(),adder(2)); What's the problem with this? Well, after *increasing* the value of an element, this is repositioned further to the end of the container, and consequentely modify_range will visit it again and engage in a neverending loop (modulo overflows.) For this situations you can use a special (albeit slower) variation that records the range before starting modifying the elements: template<typename Index,typename Modifier> void modify_unstable_range( Index& i,typename Index::iterator first,typename Index::iterator last, Modifier mod) { typedef std::vector<typename Index::iterator> buffer_type; buffer_type v; while(first!=last)v.push_back(first++); for(typename buffer_type::iterator it=v.begin(),it_end=v.end(); it!=it_end;i.modify(*it++,mod)); } // calling modify_unstable_range is now OK modify_unstable_range(m,m.begin(),m.end(),adder(2)); I hope my explanations are clear enough. Does this satisfy your needs? You can find attached a complete example exercising these little utilities. modify_key_range would be a simple variation on this stuff. HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3