July 2012 - Boost-users - lists.preview.boost.org

[math/distributions] invalid values for undefined moments
by Thomas Mang 26 Jul '12

26 Jul '12

Hi, According to the documentation, in boost 1-50 non-member functions of moments (e.g. mean, variance) which are not defined for a given distribution shall issue compile-time errors, or throw a domain_error at runtime otherwise. For the Cauchy Distribution, that's what it does. For the t-distribution, that's not what it does - the non-member functions happily return some complete rubbish values for mean and variance (and hence I'd also suppose standard deviation). For kurtosis and skewness it seems to work correctly but are subject to mathematical definitions. I have not tested other non-member functions. Note that there are different definitions floating around as to when a given moment is defined. The k-th moment is always defined if k < v, but in other cases opinions deviate. Wikipedia states it might be infinity under some circumstances - obviously what boost seems to having taken over. In general however I am used to - and my gut feeling the clear majority of people would have this perception; indeed I am not aware of any other source than wikipedia stating these infinity things - that moments are undefined if k >= v (see e.g. Probability and Statistics, DeGroot & Schervish 2002, for a professional textbooks and heaps of other sources). So while the boost output for variance and a t-2 distribution (or alternatively also the kurtosis of a t-4 distribution) might be considered ok by some, I'd guess to most people it would be fairly unexpected? It had been a surprise to me, at least. Code snippet: typedef boost::math::students_t_distribution<double> t_distr; // this is ok std::cout << "mean(t(2)): " << boost::math::mean( t_distr(2) ) << std::endl; // this is NOT ok - first moment not defined for given distribution std::cout << "mean(t(1)): " << boost::math::mean( t_distr(1) ) << std::endl; // this is ok std::cout << "var(t(3)): " << boost::math::variance( t_distr(3) ) << std::endl; // this might be ok or not // depending on point of view, either Inf or undefined std::cout << "var(t(2)): " << boost::math::variance( t_distr(2) ) << std::endl; // this is NOT ok - second moment not defined for the given distribution std::cout << "var(t(1)): " << boost::math::variance( t_distr(1) ) << std::endl; best, Thomas

2 1

Building Boost in Release mode
by VimalMathew＠Eaton.com 25 Jul '12

25 Jul '12

Hi, How do I build Boost in 'Release' mode for VS 10.0? Is this correct: b2 toolset=msvc-10.0 runtime-link=static link=static variant=release threading=multi -- Vimal

2 1

[MPI] all_gather() missing functionality or bug ?
by Thomas Hisch 25 Jul '12

25 Jul '12

Hello list, I discovered that the all_gather function from boost.mp throws an exception, if the local sizes of the to be gathered vector are different: terminate called after throwing an instance of 'terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::mpi::exception> >' what(): MPI_Allgather: MPI_ERR_IN_STATUS: error code in status boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::mpi::exception> >[thisch:14211] *** Process received signal *** I used the following form of the all_gather function: all_gather(comm, myvec.data(), myvec.size(), totalvec) where myvec is a std::vector<double>. As already mentioned the size of myvec can be different on each processor. The documentation [0] says that all_gather supports most uses of the MPI_Allgatherv. Therefore I am not sure if my use of all_gather is unsupported or a just a bug. all_gather works as excpected if myvec.size() is the same on all processors. ATM I use the following workaround: { //temporary all_gather fix: use MPI_Allgatherv vector<int> recvcts(numprocs); vector<int> displs(numprocs); const int nrealcoeffs = N; const int initialcoeffsperrank = nrealcoeffs/numprocs; const int remainder = nrealcoeffs%numprocs; size_t displtmp = 0; for(size_t i=0; i < numprocs; i++){ recvcts[i] = initialcoeffsperrank; if(i < remainder) recvcts[i]++; displs[i] = displtmp; displtmp += recvcts[i]; } allgradient.resize(N); MPI_Allgatherv( myvec.data(), myvec.size(), MPI_DOUBLE, totalvec.data(), recvcts.data(), displs.data(), MPI_DOUBLE, comm); } Regards Thomas [0] http://www.boost.org/doc/libs/1_50_0/doc/html/mpi/tutorial.html#mpi.c_mappi…

2 1

segfault happens when I serialize nested class in apache module
by Hassan Monfared 25 Jul '12

25 Jul '12

Hi all, Serializing simple class "A" in Apache module done without error but when I tried to serialize my complex object like "X" which has a member, type of "A", I got segfault in Apache module. ( this doesn't happen to a executable console application ) ------------------------- here is my code : --------------------- class A { private: friend class boost::serialization::access; // to enable boost "access" class to call private "serialize" method of class "A" template<class ArchT> void serialize(ArchT &ar, unsigned int version) { // method for both serializing and deserializing ar & memA; // (de)serialize member "memA" } std::string memA; // sample member public: A(){} A(std::string pmemA) : memA(pmemA) { } std::string GetMemA() { return memA; } }; class X { private: friend class boost::serialization::access; template<class ArchT> void serialize(ArchT &ar, unsigned int version) { ar & memX; ar & a; } std::string memX; A a; public: X(std::string pmemX, A pa) : memX(pmemX), a(pa) { } X(){} }; ------------------- string st=GetRandomFileName(); ofstream out(st.c_str()); boost::archive::text_oarchive out_r(out); A a("Amem"); X x("Xmem", a); out_r << x; // not works out_r << a; // works! ------------------- here is stack trace from gdb for apache ---------------- Program received signal SIGSEGV, Segmentation fault. 0xb39b846e in ?? () (gdb) backtrace #0 0xb39b846e in ?? () #1 0xb722379e in boost::serialization::typeid_system::extended_type_info_typeid_0::is_less_than(boost::serialization::extended_type_info const&) const () from /tmp/libIRSProWebApacheModule.so #2 0xb7223c61 in std::_Rb_tree<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::_M_insert_equal(boost::serialization::typeid_system::extended_type_info_typeid_0 const* const&) () from /tmp/libIRSProWebApacheModule.so #3 0xb7223b37 in boost::serialization::typeid_system::extended_type_info_typeid_0::type_register(std::type_info const&) () from /tmp/libIRSProWebApacheModule.so #4 0xb72066d2 in boost::serialization::extended_type_info_typeid<A>::extended_type_info_typeid (this=0xb735a638) at /usr/include/boost/serialization/extended_type_info_typeid.hpp:89 #5 0xb720650d in boost::serialization::detail::singleton_wrapper<boost::serialization::extended_type_info_typeid<A> >::singleton_wrapper (this=0xb735a638) at /usr/include/boost/serialization/singleton.hpp:106 #6 0xb7206572 in boost::serialization::singleton<boost::serialization::extended_type_info_typeid<A> >::get_instance () at /usr/include/boost/serialization/singleton.hpp:128 #7 0xb72064e3 in boost::serialization::singleton<boost::serialization::extended_type_info_typeid<A> >::get_const_instance () at /usr/include/boost/serialization/singleton.hpp:141 #8 0xb720637b in boost::archive::detail::oserializer<boost::archive::text_oarchive, A>::oserializer (this=0xb735a62c) at /usr/include/boost/archive/detail/oserializer.hpp:112 #9 0xb7206253 in boost::serialization::detail::singleton_wrapper<boost::archive::detail::oserializer<boost::archive::text_oarchive, A> >::singleton_wrapper (this=0xb735a62c) at /usr/include/boost/serialization/singleton.hpp:106 #10 0xb72062b8 in boost::serialization::singleton<boost::archive::detail::oserializer<boost::archive::text_oarchive, A> >::get_instance () at /usr/include/boost/serialization/singleton.hpp:128 #11 0xb71fb0ec in __static_initialization_and_destruction_1 (__initialize_p=1, __priority=65535) at /usr/include/boost/serialization/singleton.hpp:149 #12 0xb71fb161 in _GLOBAL__sub_I_IRSProWeb_InputFilter.cc(void) () at ../IRSProWeb_InputFilter.cc:242 #13 0xb7fee7fb in ?? () from /lib/ld-linux.so.2 #14 0xb7fee8e4 in ?? () from /lib/ld-linux.so.2 #15 0xb7ff2819 in ?? () from /lib/ld-linux.so.2 #16 0xb7fee61f in ?? () from /lib/ld-linux.so.2 #17 0xb7ff20c4 in ?? () from /lib/ld-linux.so.2 #18 0xb7d31be9 in ?? () from /lib/i386-linux-gnu/libdl.so.2 #19 0xb7fee61f in ?? () from /lib/ld-linux.so.2 #20 0xb7d3233a in ?? () from /lib/i386-linux-gnu/libdl.so.2 #21 0xb7d31c97 in dlopen () from /lib/i386-linux-gnu/libdl.so.2 #22 0xb7f3d100 in apr_dso_load (res_handle=0xbfffef08, path=0x8140b78 "/tmp/libIRSProWebApacheModule.so", pool=0x8140ab0) at dso/unix/dso.c:139 #23 0xb77587c7 in load_cpp_module (pool=0x8140ab0, server=0x8100ea8, server_rec=0x816dbc0, next=0x8140b50) at apache_handler.cpp:140 #24 0xb7757680 in load_handler (pool=0x8140ab0, server=0x8100ea8, server_rec=0x816dbc0, next=0x8140b50) at mod_cplusplus.c:83 #25 0xb77576d2 in load_handlers (pool=0x8140ab0, server=0x8100ea8, server_rec=0x816dbc0) at mod_cplusplus.c:89 #26 0xb7757737 in cpp_spawn_handlers (p=0x8140ab0, s=0x8100ea8) at mod_cplusplus.c:100 #27 0x0808b748 in ap_run_child_init (pchild=0x8140ab0, s=0x8100ea8) at config.c:166 #28 0x080af138 in child_main (child_num_arg=0) at event.c:2028 #29 0x080af464 in make_child (s=0x8100ea8, slot=0) at event.c:2169 #30 0x080af5ae in startup_children (number_to_start=3) at event.c:2233 #31 0x080afeba in event_run (_pconf=0x80dc0a8, plog=0x813caa0, s=0x8100ea8) at event.c:2561 #32 0x0806fa6d in ap_run_mpm (pconf=0x80dc0a8, plog=0x813caa0, s=0x8100ea8) at mpm_common.c:98 #33 0x08068fc4 in main (argc=2, argv=0xbffff3b4) at main.c:777

1 0

[interprocess] Strange behaviour after push_back in a b::i::vector of b::i::weak_ptr
by Gaetan Gaumer 24 Jul '12

24 Jul '12

Hello Ion a others interprocess guru, I'm currently using an interprocess::vector storing intreprocess::weak_ptr to data. Sometimes after adding a shared_ptr to my vector with push_back, the weak_ptr stored at the end of the vector is not the one I just inserted, but a copy of a previously inserted weak_ptr. For examples the code below : void addData (const SharableDataTypes<Data>::SharedPtrType & PData){ dataWPVector.push_back(PData); if (dataWPVector.rbegin()->lock()->getObjectId() != PData->getObjectId()){ std::cerr << "After pushback in dataWPVector vector last elem Id=" << dataWPVector.rbegin()->lock()->getObjectId() << " added cable Id =" << PData->getObjectId() << std::endl; } } spills the trace : "After pushback in dataWPVector vector last elem Id=50332165 added elem Id =352322053" which should obviously not happen. By adding some traces to the file : boost/interprocess/containers/container/vector.hpp I found that this case only happens during a resizing step when the method priv_range_insert_expand_backwards is used and in one of the 8 cases I labeled "4/8 and NOT do_after" (see http://pastebin.com/bLBwiBia line 41) For easier test, I created a sample code which try to reproduce the problem : http://pastebin.com/rdpZA7CU (Note : I used multiIndex to be the closest to our code). I compiled it with gcc44 (GCC) 4.4.0 20090514 (Red Hat 4.4.0-6) on a 64b Red Hat Enterprise Linux Server release 5.4 server using Boost V1.47 with the command : gcc44 -std=c++0x -m64 -I/path_to_boot/boost_1_47_0/include/ -lrt -lstdc++ testPushBackVector.cc -o testPushBackVector Note that this program does not reproduce the problem, as when it runs, only the priv_range_insert_new_allocation method is called. I don't know how to force the program to use priv_range_insert_expand_backwards to reproduce the problem. So now, the question : Am I doing something wrong or is this a bug ? Thanks for your help, Gaëtan

3 8

Conflict between boost::bind and winsock's bind function
by VimalMathew＠Eaton.com 24 Jul '12

24 Jul '12

Hi, I'm using winsock's bind function in my code. After adding a bunch of header files related to boost for some other added functionality, I'm getting this error: error C2668: 'boost::bind' : ambiguous call to overloaded function 1> c:\boost_1_49_0\boost\bind\bind.hpp(1480): could be 'boost::_bi::bind_t<R,F,L> boost::bind<SOCKET,sockaddr*,unsigned int>(F,A1,A2)' 1> with 1> [ 1> R=boost::_bi::unspecified, 1> F=SOCKET, 1> L=boost::_bi::list2<boost::_bi::value<sockaddr *>,boost::_bi::value<unsigned int>>, 1> A1=sockaddr *, 1> A2=unsigned int 1> ] How do I specify that I want to use winsock's bind function and not boost's? -- Vimal

2 1

Concept check negation
by Alexander Stoyan 24 Jul '12

24 Jul '12

Hi all, Is there any way to negate concept check, so that it'd be possible to assert if a type is NOT DefaultConstructible, etc. ? Thanks in advance. ============================== Never lose heart! Regards, Alexander Stoyan e-mail: alexander.stoyan, you know, at google mail dot com gtalk: alexander.stoyan, you know, at google mail dot com skype: alexander.stoyan <http://alexander-stoyan.blogspot.com/> http://alexander-stoyan.blogspot.com

2 1

Re: [Boost-users] Missing libboost_thread-vc100-mt-s-1_49.lib
by VimalMathew＠Eaton.com 24 Jul '12

24 Jul '12

Anybody? -- Vimal -----Original Message----- From: Mathew, Vimal Sent: Friday, July 20, 2012 2:32 PM To: boost-users(a)lists.boost.org Subject: Missing libboost_thread-vc100-mt-s-1_49.lib Hi, I'm trying to build a project using nmake. When I run nmake I get this error message: " LINK : fatal error LNK1104: cannot open file 'libboost_thread-vc100-mt-s-1_49.lib " Could someone tell me what I'm missing please? Thanks, Vimal

4 10

[move] case study: simple cloning smart pointer
by Krzysztof Czainski 24 Jul '12

24 Jul '12

Hello, In order to learn how to implement move semantics, I decided to write a simple cloning smart pointer (called ptr) with diagnostic information, and an example showing all constructor and assignment use cases I could think of. I wanted the pointer to be convertible (and movable) to pointers to base classes. I've prepared two versions of conversion constructors and assignment operators in ptr. In the first version I tried to write everything like Boost.Move docs for implementing Copyable and Movable classes suggest, and then added the conversion constructors and assignment operators. Then I wrote a second version, using the pass-by-value and swap idiom. Any comments about my attempts here are welcome. Did I get it right in both versions? The attached file swap_idiom.zip contains: ptr.hpp - the deffinition of the ptr class template main.cpp - example for ptr<>, showing all constructor and assignment use cases I could think of 03.txt, 03_by_value.txt, 0x.txt, 0x_by_value.txt - the output I got for both versions of ptr, in two versions of C++: 03 and 0x. For this test I used MinGW-4.5.0. Here's how the ptr<> class looks like (ptr.hpp) (note: {{{this}}} is how I mark code): {{{ extern int ptr_s; // helper for diagnostics template < class T > T* clone_me( T const* p ); template < class T > class ptr { public: explicit ptr( T* p = 0 ) : p_(p) { ++ptr_s; std::cout << "_p "; } // copy ctor ptr( ptr const& b ) : p_( clone_me(b.get()) ) { ++ptr_s; std::cout << "cp "; } // move ctor ptr( BOOST_RV_REF(ptr) b ) : p_( b.release() ) { ++ptr_s; std::cout << "mp "; } }}} So far so good. This is where the hard part comes in - the conversion constructors and assignment operators. First version looks like this: {{{ private: #if !defined(BY_VALUE) BOOST_COPYABLE_AND_MOVABLE(ptr) public: // generalized copy ctor for pointers to derived template < class U > ptr( ptr const& b, typename boost::enable_if< boost::is_convertible<U*,T*> >::type* = 0 ) : p_( clone_me(b.get()) ) { ++ptr_s; std::cout << "Cp "; } // generalized move ctor for pointers to derived template < class U > ptr( BOOST_RV_REF(ptr) b, typename boost::enable_if< boost::is_convertible<U*,T*> >::type* = 0 ) : p_( b.release() ) { ++ptr_s; std::cout << "Mp "; } ptr& operator=( BOOST_COPY_ASSIGN_REF(ptr) b ) { T* tmp = clone_me(b.get()); // this can throw boost::checked_delete(p_); p_ = tmp; return *this; } ptr& operator=( BOOST_RV_REF(ptr) b ) { boost::checked_delete(p_); p_ = b.release(); return *this; } template < class U > typename boost::enable_if< boost::is_convertible<U*,T*>, ptr& >::type operator=( ptr const& b ) { T* tmp = clone_me(b.get()); // this could throw boost::checked_delete(p_); p_ = tmp; return *this; } template < class U > typename boost::enable_if< boost::is_convertible<U*,T*>, ptr& >::type operator=( BOOST_RV_REF(ptr) b ) { boost::checked_delete(p_); p_ = b.release(); return *this; } }}} This was long, and contains some tricky places, like the one commented 'this could throw'. Did I even get it right? I think so, but I'm just beginning to learn about move semantics here ;-) Anyway, next comes the second version: implementing conversion constructors and assignment operators in terms of pass-by-value and swap. Note the use of BOOST_COPYABLE_AND_MOVABLE_ALT macro so that an operator=(ptr&) isn't inserted. {{{ #else // BY_VALUE BOOST_COPYABLE_AND_MOVABLE_ALT(ptr) public: // generalized copy/move constructor implemented by pass-by-value & steal template < class U > ptr( ptr b, typename boost::enable_if< boost::is_convertible<U*,T*> >::type* = 0 ) : p_( b.release() ) { ++ptr_s; std::cout << "Vp "; } // assignment - works for all types convertible to ptr ptr& operator=( ptr b ) { swap(*this,b); return *this; } #endif // BY_VALUE }}} Compared to the first version, this is really simple. I see no tricky parts here. The rest of ptr<> follows: {{{ ~ptr() { boost::checked_delete(p_); ++ptr_s; std::cout << "~p "; } T* get() const { return p_; } T* release() { T* r = p_; p_ = 0; return r; } friend void swap( ptr& a, ptr& b ) { boost::swap(a.p_,b.p_); std::cout << "sp "; } // reset, operator* and -> private: T* p_; }; }}} Writing the conversion constructors and assignment operators in the second version was much simpler. While version 1 contains 6 functions, version 2 contains only 2 functions. But is this always correct, and what is the cost of simplifying things? I tried to answer that question by writing the example (main.cpp). I started by preparing two diagnostic classes: {{{ struct A { static int a, c; A() { ++a; ++c; cout << "_A "; } A( A const& ) { ++a; ++c; cout << "cA "; } virtual ~A() { ++a; --c; cout << "~A "; } }; int A::a = 0; int A::c = 0; struct B : A { static int b, d; B() { ++b; ++d; cout << "_B "; } B( B const& x ) : A(x) { ++b; ++d; cout << "cB "; } ~B() { ++b; --d; cout << "~B "; } }; int B::b = 0; int B::d = 0; ptr<A> make_a() { return ptr<A>( new A ); } ptr make_b() { return ptr( new B ); } }}} Then some machinery for printing and zeroing the static variables incremented/decremented by corresponding constructors/destructors. {{{ void trace( char const* msg ) { cout << endl << boost::format("%34s P:%d A:%d B:%d eA:%d eB:%d") % msg % ptr_s % A::a % B::b % A::c % B::d << endl; ptr_s = 0; A::a = 0; B::b = 0; } #define TRACE( x ) x; trace( #x ); }}} And now main() itself, containing all use cases of ptr<> I could think of: {{{ int main() { { TRACE( ptr<A> z ) TRACE( ptr<A> a( new A ) ) TRACE( ptr b( new B ) ) TRACE( ptr<A> c( new B ) ) TRACE( ptr<A> d( a ) ) TRACE( ptr<A> e( b ) ) TRACE( ptr<A> f( boost::move(a) ) ) TRACE( ptr<A> g( boost::move(b) ) ) TRACE( ptr h( new B ) ) TRACE( ptr<A> i( boost::move(c) ) ) TRACE( ptr<A> j( i ) ) // slice TRACE( ptr<A> x( new A ) ) TRACE( x = f ) TRACE( x = h ) TRACE( x = boost::move(f) ) TRACE( x = boost::move(g) ) TRACE( x = boost::move(h) ) TRACE( x = i ) // slice } trace( "" ); { TRACE( ptr<A> a = make_a() ) TRACE( ptr<A> b = make_b() ) TRACE( ptr<A> c( make_b() ) ) TRACE( a = make_a() ) TRACE( b = make_b() ) } trace( "" ); } }}} And now for the costs. I compiled the attached code with MinGW-4.5.0 in 4 configurations: -std=c++0x disabled/enabled, and version 1/2. I compared the program output to derive the conclusions: C++03: version 1 vs. version 2: - whenever a conversion is needed (about half of the use cases above), version 2 introduces an additional temporary ptr<> object (without a deep copy); in one case it's 2 additional temporary ptr<>s; - the last 4 use cases {{{ ptr<A> b = make_b(); ptr<A> c( make_b() ); a = make_a(); b = make_b(); }}} introduce a deep copy in version 1, while while the deep copy is avoided in version 2. C++0x: version 1. vs. version 2: - whenever a conversion is needed (about half of the use cases above), version 2 introduces an additional temporary ptr<> object (without a deep copy); in one case it's 2 additional temporary ptr<>s; - no unnecessary deep copies are introduced in either version. Version 1: C++03 vs. C++0x: - the last 4 use cases {{{ ptr<A> b = make_b(); ptr<A> c( make_b() ); a = make_a(); b = make_b(); }}} introduce a deep copy in version C++03, while while the deep copy is avoided in C++0x. Version 2: C++03 vs. C++0x: - no difference. General conclusion: 'pass-by-value and swap' idiom is cool ;-) Pros: - better move emulation, - simple implementation. Cons: - additional temporary objects, that are then swapped to the right place. Thanks for staying with me ;-) Regards, Kris

3 6

[serialization - eceptions] Could not catch exceptions
by DaBoneCrack 24 Jul '12

24 Jul '12

Hi, i could not catch boost serialization exceptions. By default BOOST_NO_EXCEPTIONS is defined. All attempts to undefine it has no effect. What i try to do: <code> ... #include <boost/config.hpp> #ifdef BOOST_NO_EXCEPTIONS # undef BOOST_NO_EXCEPTIONS #endif ... more boost serialization headers included .... try { std::ifstream ifs("D:\\tmp.bin", std::ios::binary); boost::archive::binary_iarchive ia(ifs); int iIndex = 0; ia >> BOOST_SERIALIZATION_NVP("A", iIndex); ... } catch(std::exception) { ... } </code> Do i miss something to catch boost serialization exceptions? I am using vs2008. Thx for your help. -- View this message in context: http://boost.2283326.n4.nabble.com/serialization-eceptions-Could-not-catch-… Sent from the Boost - Users mailing list archive at Nabble.com.

1 0