- Boost-users - lists.boost.org

question about threading library
by Robert Ramey 07 Nov '08

07 Nov '08

I want to use the boost threading library in an application. Looking through the documentation, I have a questions. a) in the examples I find "boost::mutex::scoped_lock" but I don't find this in the documentation. It looks like this is called "lock_guard". What should I be doing here. b) Its not clear to me how unique_lock(Lockable l) is different than using lock_gard(..) or scoped_lock. Robert Ramey

5 6

[program_options] Using multitokens
by Ryan McConnehey 07 Nov '08

07 Nov '08

In the example documentation a multitoken is used for strings as follows: ("email", boost::program_options::valuevalue<std::string>()->multitoken(), "email to send to") This means the command line can have the following option. --email beadle@mars beadle2@mars I'm trying to use the multitoken with an unsigned long as follows: ("sending,s", boost::program_options::value<unsigned long>()->multitoken(), "Distination node address and port number to transmit data.") The command option I would like to use is: -s 23 6543 When trying to do this the following error occurs. Unhandled exception: in option 'sending': multiple values not allowed How do I correctly define a multitoken and then how do I retrieve the different values? Ryan

3 6

Happy Camper
by Rush Manbert 07 Nov '08

07 Nov '08

Yesterday, all in one day, I had to make my first use of the Boost Date Time library, the Threads library, and the Random Number library. As has been my experience in the past, all of them were easy to use and they just worked as advertised for my application. We all know that the libraries aren't perfect, or there would be hardly any traffic on this list. :-) But I would like to say thank you to all of the people involved in developing and releasing the libraries. They are immensely useful and are of extremely high quality. - Rush

1 0

#include <boost/asio.hpp> makes installshield's "Extract COM Interface" get bad winsock2 registry settings
by Kevin McMahon 07 Nov '08

07 Nov '08

All I have to do is #include <boost/asio.hpp>. I tried boost 1.35 and boost 1.37 with Visual Studio 2008. If it is included, InstallShield's RegSpyUI (or it's "Extract COM Interface" step) gets bad Winsock2 registry settings. When InstallShield applies those settings, it screws up the machine. Most notably, DNS is disabled. The registry settings that appear are: HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Services\ WinSock2\ Parameters\ WinSock_Registry_version==>2.0 NameSpace_Catalog5\ Num_Catalog_Entries==>0 Serial_Access_Num==>1 Catalog_Entries\ Protocol_Catalog9\ Num_Catalog_Entries==>0 Next_Catalog_Entry_ID==>-23 Serial_Access_Num==>1 Catalog_Entries\ I don't know where they come from. I'm still trying to figure it out. If anyone has any advice, I'd be grateful. Thanks, Kevin McMahon kevinmcm(a)alum.mit.edu

1 0

Visitor Pattern Implementation
by Rodrigo Madera 07 Nov '08

07 Nov '08

Dear community, Is there any implementation/helper/inspiration/or-alike in Boost for the Visitor Pattern? I know of Boost Signals, which is awesome, but (as stated in the FAQ) it's not Thread-safe (yikes!). Thank you for your kind input, Rodrigo

3 4

[Regex] 1.37.0: Truncation warning under Windows
by Peter Klotz 07 Nov '08

07 Nov '08

MSCV8 gives this warning when compiling Boost.Regex 1.37.0 under Windows x86 (32 Bit): libs\regex\src\..\src\cregex.cpp(563) : warning C4309: 'static_cast' : truncation of constant value The code that produces the warning: #ifdef BOOST_HAS_LONG_LONG const std::size_t RegEx::npos = static_cast<std::size_t>(~0ULL); #else const std::size_t RegEx::npos = static_cast<std::size_t>(~0UL); #endif In Windows x86 sizeof(unsigned long long int) is 8, sizeof(std::size_t) is 4 and BOOST_HAS_LONG_LONG is defined. Therefore "~0ULL" is truncated from 8 to 4 bytes. Maybe a better trigger would be the architecture (32 Bit or 64 Bit) since in all environments I know sizeof(std::size_t) equals the architecture. Regards, Peter.

1 0

[bjam] Generated path approaches 255 character OS limit
by Peter Klotz 07 Nov '08

07 Nov '08

When compiling Boost 1.37.0 using this bjam command line under Windows I obtained the error message below: bjam -q -sNO_COMPRESSION=1 --build-type=complete --without-graph --without-math --without-mpi --without-python --without-serialization --without-signals --without-wave --toolset=msvc-8.0 architecture=x86 address-model=64 failed to write output file 'bin.v2\libs\test\build\msvc-8.0\debug\address-model-64\architecture-x86\asynch-exceptions-on\link-static\runtime-link-static\threading-multi\libboost_prg_exec_monitor-vc80-mt-sgd-1_37.lib.rsp'! Obviously the path I started from (70 characters) combined with the bjam generated path (192 characters) exceeds the OS limit of 255 characters per filename. Does the bjam generated path really have to be this long? Can I shorten it somehow? If future versions of bjam encode even more information into the generated path it may not be possible to build Boost even when building in directory C:\Boost. Regards, Peter.

6 10

Re: [Boost-users] Boost-users] question about threading library
by Tan, Tom (Shanghai) 07 Nov '08

07 Nov '08

Please read this link by the author of boost.thread: http://www.devx.com/SpecialReports/Article/38883/1954?pf=true, He also has a personal blog worth reading: http://www.justsoftwaresolutions.co.uk/ concerning your specific questions: 1. boost::mutex::scoped_lock is just a typedef of unique_lock<mutex> inside mutex. With this kind of typedef, you'll be able to use the same type scoped_lock for other kind of mutex( For example Timed_mutex ) by changing the mutex type only. There IS the definition on this page: http://www.boost.org/doc/libs/1_37_0/doc/html/thread/synchronization.htm l#thread.synchronization.mutex_types 2. " std::lock_guard is deliberately basic and can only be used as shown. On the other hand, std::unique_lock allows for deferred locking, trying to lock, trying to lock with a timeout, and unlocking before the object is destroyed. "(copied from the first link above) HTH. >From: "Robert Ramey" <ramey(a)rrsd.com> >Subject: [Boost-users] question about threading library > >I want to use the boost threading library in an application. > >Looking through the documentation, I have a questions. >a) in the examples I find "boost::mutex::scoped_lock" but >I don't find this in the documentation. It looks like this >is called "lock_guard". What should I be doing here. >b) Its not clear to me how unique_lock(Lockable l) >is different than using lock_gard(..) or scoped_lock. >Robert Ramey **************************************

1 0

[random] streamable state of normal_distribution to ostream not accurate
by Oei, YC 07 Nov '08

07 Nov '08

Dear list members, I'm using the Boost Random Number Library, and am now trying to store the state of an instance of normal_distribution by means of its << operator. It doesn't however seem to work: three of its data members are definitely not outputting properly on my system. I can reproduce the problem with this test file: ----- #include <boost/random/mersenne_twister.hpp> #include <boost/random/variate_generator.hpp> #include <boost/random/normal_distribution.hpp> #include <iomanip> #include <iostream> #include <limits> using namespace boost; using namespace std; int main() { mt19937 rng; normal_distribution<> gauss; variate_generator<mt19937&, normal_distribution<> > var(rng, gauss); cerr << setprecision(numeric_limits<double>::digits10 * 2); for (size_t i = 0; i != 5; ++i) { cerr << var() << endl; //prints a random number cerr << gauss << endl; //dumps object internal state } //for } //main ----- which, on Ubuntu 8.04 amd64 (gcc 4.2.4, boost 1.34.1) produces this output: 0.21343601372288967255030911474 0 1 0 6.95335189373114898041666608493e-310 6.9533518937319394854500120794e-310 -0.495580282118778303601658308253 0 1 0 6.95335189373114898041666608493e-310 6.9533518937319394854500120794e-310 1.57537639010992913668474102451 0 1 0 6.95335189373114898041666608493e-310 6.9533518937319394854500120794e-310 -1.05920392793252360341682560829 0 1 0 6.95335189373114898041666608493e-310 6.9533518937319394854500120794e-310 1.83926543714107570970384131215 0 1 0 6.95335189373114898041666608493e-310 6.9533518937319394854500120794e-310 ...and I get similar output on an OpenSuse 10.2 x86_64 system (gcc 4.1.2, boost 1.33.1). If I understand the code in boost/random/normal_distribution.hpp correctly, the third member in the stream represents _valid and should alternate between 0 and 1, and the last two values should definitely not stay the same for five iterations. Can you tell me if I'm doing anything wrong? (And, slightly offtopic, what should I set the stream-precision at to ensure exact reloading of the floating point data?) Many thanks for reading and thinking about this, Yung-Chin Oei

2 2

#include <boost/asio.hpp> makes installshield's "Extract COM Interface" get bad winsock2 registry settings
by Kevin McMahon 07 Nov '08

07 Nov '08

All I have to do is #include <boost/asio.hpp>. I tried boost 1.35 and boost 1.37 with Visual Studio 2008. If it is included, InstallShield's RegSpyUI (or it's "Extract COM Interface" step) gets bad Winsock2 registry settings. When InstallShield applies those settings, it screws up the machine. Most notably, DNS is disabled. The registry settings that appear are: HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Services\ WinSock2\ Parameters\ WinSock_Registry_version==>2.0 NameSpace_Catalog5\ Num_Catalog_Entries==>0 Serial_Access_Num==>1 Catalog_Entries\ Protocol_Catalog9\ Num_Catalog_Entries==>0 Next_Catalog_Entry_ID==>-23 Serial_Access_Num==>1 Catalog_Entries\ I don't know where they come from. I'm still trying to figure it out. If anyone has any advice, I'd be grateful. Thanks, Kevin McMahon kevin(a)pando.com Kevin McMahon kevinmcm(a)alum.mit.edu

1 0