April 2010 - Boost-users - lists.preview.boost.org

boost::thread 1.40 doesn't build on Sun
by Conoscenza Silente 13 Apr '10

13 Apr '10

Hi All I found in Sun Solaris machine I have the version 1.40 of boost and not the last one as I thought. and each time I try to use a thread with a shared pointer I receive this message. "/opt/boost/boost/thread/detail/thread.hpp", line 344: Error: boost::thread::thread(boost::thread&) is not accessible from boost::move(boost::detail::thread_move_t<boost::thread>). 1 Error(s) detected. I am trying to use thread using code like this below boost::shared_ptr< boost::thread > m_ThreadListener( new boost::thread( funct) ); Do you know a solution for this issue? Reading posts it seems that I should rebuild the library.. ..is this correct or there is some workaround? Thanks AFG

1 0

[string algorithms] trim, functors
by Gaydov Victor 13 Apr '10

13 Apr '10

Hello. Could you answer these two questions: 1. Are there trim range algorithms that work with iterators, instead of strings? (I didn't find such). If not, why not to add them? Something like this: http://pastebin.org/146696 2. How can I use, for example, boost::algorithm::is_space() with standard functors? This: boost::not1(boost::algorithm::is_space()) doesn't work. It's enough to specialize boost::unary_traits<boost::algorithm::detail::is_classifiedF>, but the fact that 'is_classifiedF' is in 'detail' namespace is a bit confusing. Is it ok to use it? Thanks.

3 5

Boost.Thread and debugging a memory error
by Braden McDaniel 13 Apr '10

13 Apr '10

I'm trying to debug a memory error and this is among the suspicious bits that valgrind is turning up: ==23982== Invalid read of size 1 ==23982== at 0x583DAFA: boost::detail::interruption_checker::interruption_checker(pthread_cond_t*) (thread_data.hpp:94) ==23982== by 0x583DC35: boost::condition_variable::wait(boost::unique_lock<boost::mutex>&) (condition_variable.hpp:19) ==23982== by 0x583DECE: boost::shared_mutex::lock_shared() (shared_mutex.hpp:64) ==23982== by 0x5849E63: boost::shared_lock<boost::shared_mutex>::lock() (locks.hpp:575) ==23982== by 0x583E988: boost::shared_lock<boost::shared_mutex>::shared_lock(boost::shared_mutex&) (locks.hpp:458) I am pretty confident that the shared_mutex is fully constructed when this happens. Also, this is coming from the main thread. I'm just not sure what's going on here. As I continue to explore this, I thought I'd try my luck here: perhaps someone's seen something like this before? -- Braden McDaniel <braden(a)endoframe.com>

1 0

Possible bug: regex, lexical_cast
by John.X.Foster＠nab.com.au 13 Apr '10

13 Apr '10

Hi all I have come across a bug associated with lexical_cast and regex (though the culprit may well be the Visual C++ compiler). I have stripped the code to the bare essentials. This worked OK under VC++ 8 (2005), but gives an access violation under VC++ 9 (2008). This occurs with both boost 1.39 and 1.42. Simplified code follows: #define _SECURE_SCL 0 #define _HAS_ITERATOR_DEBUGGING 0 #include <boost/lexical_cast.hpp> #include <boost/regex.hpp> #include <string> #include <iostream> void violate() { int i = 0; std::string x = "x" + boost::lexical_cast<std::string>(i); boost::regex regex("aaa"); boost::regex_replace(x, regex, "bbb", boost::match_default); } int main() { violate(); std::cout << "Enter to exit\n"; std::cin.get(); } In debug mode, the following exception message is generated: Unhandled exception at 0x10487b3f (msvcp90d.dll) in RegexBug.exe: 0xC0000005: Access violation writing location 0xcccccccc. Stack at time of exception is: msvcp90d.dll!std::_Container_base_secure::_Orphan_all() Line 223 + 0x5 bytes C++ msvcp90d.dll!std::_Container_base_secure::~_Container_base_secure() Line 115 C++ msvcp90d.dll!std::_String_base::~_String_base() + 0x11 bytes C++ msvcp90d.dll!std::_String_val<unsigned short,std::allocator<unsigned short> >::~_String_val<unsigned short,std::allocator<unsigned short> >() + 0x11 bytes C++ msvcp90d.dll!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string<char,std::char_traits<char>,std::allocator<char> >() Line 917 + 0xf bytes C++ RegexBug.exe!violate() Line 16 + 0x1e bytes C++ RegexBug.exe!main() Line 21 C++ RegexBug.exe!__tmainCRTStartup() Line 586 + 0x19 bytes C RegexBug.exe!mainCRTStartup() Line 403 C kernel32.dll!7c817067() [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] While I have found several work-arounds, it would be useful to log this, if it is a bug, in the correct place - boost? MS? Appologies for the extended junk at the end of this email! John John Foster Senior Quantitative Credit Developer Model Development, Group Credit Portfolio & Models National Australia Bank Level 15, 500 Bourke St, Melbourne VIC 3000 Tel: +61 (0)3 8641 5228 Email: John.X.Foster(a)nab.com.au This e-mail is sent by or on behalf of the named sender identified above. If: (a) you do not wish to receive any e-mail marketing material from this person in the future, please forward the contents of this email to unsubscribe(a)nab.com.au with the word "unsubscribe" in the subject box. (b) you wish to unsubscribe from all central e-mail marketing lists used by our business, please forward the contents of this e-mail to unsubscribeall(a)nab.com.au with the message "unsubscribe from all central e-mail marketing lists" in the subject box. If you do not forward the contents of this e-mail with your unsubscription then it may not be able to be implemented. The information contained in this e-mail communication may be confidential. You should only read, disclose, re-transmit, copy, distribute, act in reliance on or commercialise the information if you are authorised to do so. If you are not the intended recipient of this e-mail communication, please immediately notify us by e-mail to postmaster(a)nab.com.au, or reply by e-mail direct to the sender and then destroy any electronic and paper copy of this message. Any views expressed in this e-mail communication are those of the individual sender, except where the sender specifically states them to be the views of a member of the National Australia Bank Group of companies. Any advice contained in this e-mail has been prepared without taking into account your objectives, financial situation or needs. Before acting on any advice in this e-mail, National Australia Bank Limited recommends that you consider whether it is appropriate for your circumstances. If this e-mail contains reference to any financial products, the National recommends you consider the Product Disclosure Statement (PDS) or other disclosure document before making any decisions regarding any products. The National Australia Bank Group of companies does not represent, warrant or guarantee that the integrity of this communication has been maintained nor that the communication is free of errors, virus or interference.

3 5

[serialization] Will a void_caster fix be available for 1.43?
by Bogdan 13 Apr '10

13 Apr '10

I try again: is there any chance for a fix to this problem to make it into 1.43.0? I get an access violation after explicitly unloading a DLL that contains serialization code for a series of classes. I believe there might be a bug in void_caster::recursive_unregister(): that function member is called in the destructors of the void caster template classes. It searches the set inside void_caster_registry singleton for all the entries that are descendants of the current one (i.e., the void_caster being destroyed) and performs the following operations: - delete the shortcuts. - remove the corresponding entries from the set. However, void_caster::recursive_unregister() doesn't remove from the registrar the entry corresponding to the current void_caster(). This creates the problem below: Consider a scenario where a dll containing some serialization functionality is loaded explicitly at runtime (i.e., using LoadLibrary() on Windows or dlopen on Unix). There are no parent-child relationships among the serialized classes registered by that DLL: all serialized classes are derived from one abstract base. While unloading the library, its void_caster singletons are destroyed but there are no shortcuts to remove from the global registrar since there are no parent-child relationships. All entries corresponding to those are still in the global registrar and point to the void_caster singletons ALREADY DESTROYED AND DISCARDED. When the main process exits, the registrar repeats the traversal for whatever executable-bound void_caster singletons are about to be destroyed. During these subsequent traversals, void_caster::recursive_unregister() visits the entries left after the previous explicit dll download and tries to identify the parent-child relationship. In doing so, it accesses the dangling vc pointers generating access violations: void_cast.cpp(Line 286): const void_caster * vc = *it; void_cast.cpp(Line 287): if(vc->m_parent == this){ //<--------------------- here is the access violation I can reproduce the crash systematically, but I am not 100% sure about the reason or whether a simple unregistration is enough. Thank you, Bogdan

1 0

Re: [Boost-users] [serialization] Potential problems with void_caster
by Bogdan 12 Apr '10

12 Apr '10

I try again: is there any chance for a fix to this problem to make it into 1.43.0? I get an access violation after explicitly unloading a DLL that contains serialization code for a series of classes. I believe there might be a bug in void_caster::recursive_unregister(): that function member is called in the destructors of the void caster template classes. It searches the set inside void_caster_registry singleton for all the entries that are descendants of the current one (i.e., the void_caster being destroyed) and performs the following operations: - delete the shortcuts. - remove the corresponding entries from the set. However, void_caster::recursive_unregister() doesn't remove from the registrar the entry corresponding to the current void_caster(). This creates the problem below: Consider a scenario where a dll containing some serialization functionality is loaded explicitly at runtime (i.e., using LoadLibrary() on Windows or dlopen on Unix). There are no parent-child relationships among the serialized classes registered by that DLL: all serialized classes are derived from one abstract base. While unloading the library, its void_caster singletons are destroyed but there are no shortcuts to remove from the global registrar since there are no parent-child relationships. All entries corresponding to those are still in the global registrar and point to the void_caster singletons ALREADY DESTROYED AND DISCARDED. When the main process exits, the registrar repeats the traversal for whatever executable-bound void_caster singletons are about to be destroyed. During these subsequent traversals, void_caster::recursive_unregister() visits the entries left after the previous explicit dll download and tries to identify the parent-child relationship. In doing so, it accesses the dangling vc pointers generating access violations: void_cast.cpp(Line 286): const void_caster * vc = *it; void_cast.cpp(Line 287): if(vc->m_parent == this){ //<--------------------- here is the access violation I can reproduce the crash systematically, but I am not 100% sure about the reason or whether a simple unregistration is enough. Thank you, Bogdan

1 0

Re: [Boost-users] math round() functions: away from 0
by Hicham Mouline 12 Apr '10

12 Apr '10

Apologies for the non-text formatting. Here is the same message in pure text: Hello, boost/trunk/libs/math/doc/sf_and_dist/html/math_toolkit/utils/rounding/round.html says that: Halfway cases are rounded away from zero, regardless of the current rounding direction. This I believe is compatible with C99 TC3 and therefore the latest C++1x draft. However, when I ran this program: #include <cmath> #include <iostream> #include <boost/math/special_functions/round.hpp> inline double round1(double x) { if (x >= 0.0) return std::floor(x + 0.5); else return std::ceil(x - 0.5); } inline double round2(double x) { return std::floor(x + 0.5); } int main() { std::cout.setf(std::ios_base::fixed, std::ios_base::floatfield); std::cout.precision(1); std::cout<< "d floor/ceil.5 floor.5 boostmathround"<<std::endl; for (double d=-10.5; d<11; d+=0.5) std::cout<< d<<" "<< round1(d)<<" "<<round2(d)<<" "<< boost::math::iround<double>(d)<<std::endl; return 0; } under g++4.3.x and msvc2008 with trunk, the output for all the negative halves does not seem to be away from 0. The same for boost::math::round<double>(d) This stuff most likely depends on the bit pattern, so I investigated further. I raised the precision of std::cout to 18 decimals. I then rounded this: const double dd = -10.5; which yielded dd floor/ceil.5 floor.5 boostmathround -10.500000000000000000 -11.000000000000000000 -10.000000000000000000 -10 and for (double d=-10.6; d<-10.4; d+=0.01) std::cout<< d<<" "<< round1(d)<<" "<<round2(d)<<" "<< boost::math::iround(d)<<std::endl; -10.600000000000000000 -11.000000000000000000 -11.000000000000000000 -11 -10.590000000000000000 -11.000000000000000000 -11.000000000000000000 -11 -10.580000000000000000 -11.000000000000000000 -11.000000000000000000 -11 -10.570000000000000000 -11.000000000000000000 -11.000000000000000000 -11 -10.560000000000000000 -11.000000000000000000 -11.000000000000000000 -11 -10.550000000000001000 -11.000000000000000000 -11.000000000000000000 -11 -10.540000000000001000 -11.000000000000000000 -11.000000000000000000 -11 -10.530000000000001000 -11.000000000000000000 -11.000000000000000000 -11 -10.520000000000001000 -11.000000000000000000 -11.000000000000000000 -11 -10.510000000000002000 -11.000000000000000000 -11.000000000000000000 -11 -10.500000000000002000 -11.000000000000000000 -11.000000000000000000 -11 -10.490000000000002000 -10.000000000000000000 -10.000000000000000000 -10 -10.480000000000002000 -10.000000000000000000 -10.000000000000000000 -10 -10.470000000000002000 -10.000000000000000000 -10.000000000000000000 -10 -10.460000000000003000 -10.000000000000000000 -10.000000000000000000 -10 -10.450000000000003000 -10.000000000000000000 -10.000000000000000000 -10 -10.440000000000003000 -10.000000000000000000 -10.000000000000000000 -10 -10.430000000000003000 -10.000000000000000000 -10.000000000000000000 -10 -10.420000000000003000 -10.000000000000000000 -10.000000000000000000 -10 -10.410000000000004000 -10.000000000000000000 -10.000000000000000000 -10 -10.400000000000004000 -10.000000000000000000 -10.000000000000000000 -10 -10.5 has the exact representation in IEEE754 as the 64bit: 0000000000000000000000000000000000000000000000001010010000000011 with the bits listed from least significant to most, across all bytes. It is an _exact_ representation as far as I can tell. therefore there are no hidden issues, and the boost math round() function should round _away_ from 0, to give -11, shouldn't it? the above round1() function seems to do the right thing.... Regards,

1 0

Choosing a variable size
by John Dlugosz 12 Apr '10

12 Apr '10

Given a template function that has two incoming integral types to work with, I want to declare some variables for intermediate use. How do I easily make a typedef for the larger of the two? It doesn't need to be perfect. I'm just trying to avoid using a 64-bit integer when it isn't needed, since 32-bit targets will be penalized for that. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

3 2

[interprocess] managed_shm->find call causes assertion
by Moritz 12 Apr '10

12 Apr '10

Hi, I have a managed_shared_memory segment which contains a unique_instance of an object. When I try to call managed_shm->find<ObjectType>( ipc::unique_instance ); I get the following assertion: /usr/include/boost/interprocess/sync/posix/interprocess_recursive_mutex.hpp:110: void boost::interprocess::interprocess_recursive_mutex::unlock(): Assertion `res == 0' failed. Aborted This only happens in Release-Mode (with gcc -s -O2). I am not able to build a minimum example but I also can not track the problem. Any suggests? Kind regards

2 7

[Boost.mpi] Installation with Intel compilers
by Federico Golfrè Andreasi 12 Apr '10

12 Apr '10

Hi, I'm trying to build the boost.mpi 1.42.0 library with Intel compilers. I build the other libraries, so I believe it's just a matter of rightly configure everything. I've the bootstrap ./bootstrap.sh --with-toolset=intel-linux --with-libraries=mpi --prefix=/usr/local/boost-1.42.0-intelmpi I've added to the file project-config.jam the following row: using mpi : mpiicpc ; and then I run the bjam: ./bjam --with-mpi toolset=intel link=static --debug-configuration install but I receive this failure message ...patience... ...found 16685 targets... ...updating 21 targets... intel-linux.compile.c++ bin.v2/libs/mpi/build/intel-linux/release/link-static/threading-multi/broadcast.o icpc: command line warning #10006: ignoring unknown option '-fenable-new-dtags' icpc: command line error: multiple sources not allowed with -o option "icpc" -c -xc++ -O3 -w1 -inline-level=2 -pthread $libdir --enable-new-dtags -Xlinker -rpath /opt/intel/mpi-rt/3.2.2 -DBOOST_ALL_NO_LIB=1 -DBOOST_MPI_SOURCE=1 -DNDEBUG -I"." -I"/opt/intel/impi/ 3.2.2.006/include" -c -o "bin.v2/libs/mpi/build/intel-linux/release/link-static/threading-multi/broadcast.o" "libs/mpi/src/broadcast.cpp" ...failed intel-linux.compile.c++ bin.v2/libs/mpi/build/intel-linux/release/link-static/threading-multi/broadcast.o... [...] what's wrong with my configuration steps ? thank you. Federico

2 1