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

Normal distribution
by Laurent GIORELLO 13 Dec '08

13 Dec '08

Hi all, I've read the implementation for the normal distribution and I've seen people wanted Box-Muller algorithm. Instead, I suggest Marsaglia method. Instead of using cos and sin, we use a square soot. The advantage is that we already use the square root for the log. Then it's really faster. Anybody for this ? Laurent

1 0

Abstract factory
by Jason Felice 13 Dec '08

13 Dec '08

Does boost have an abstract factory? I'm reading through Alexandrescu's "Modern C++ Design" and finding the idea neat, and I'm surprised to not find an equivalent in boost. Or alternately, is there another preferred solution?

3 3

thread_group / removal of items
by Christian Ost 13 Dec '08

13 Dec '08

Hi, I have a question concerning the removal from entries of a thread_group. Consider the following code (i am working on a small threaded server): in TCPServer.h: boost::thread_group threads in TCPServer.cpp: int TCPServer::loop(int listen_fd) { for (;;) { [connect client] boost::thread* thrd = new boost::thread(boost::bind(&TCPServer::readMessages, this, rfd)); threads.add_thread(thrd); } } } int TCPServer::readMessages(int rfd) { boost::this_thread::at_thread_exit(boost::bind(&TCPServer::exitThread, this)); for(;;) { [read message] if ([buffer is empty]) { [close connection] return(0); } } return 1; } void TCPServer::exitThread() { cout << "thread exited" << endl; } Now I would like to remove the exited thread from the thread_group, however to do this I would need its thread* object - but the maximum of information I can get from boost::this_thread is a boost::thread::id and I haven't found a possibility to get a thread by its thread::id so far. How can/should I solve this issue? I would be quite happy about any advice... Thank you very much! Christian

3 2

seeking comments on 'weak_key_map' experiments
by Nicolas Lelong 13 Dec '08

13 Dec '08

Hello, I've been doing too much Python recently - thanks to boost.python - and my return in the c++ world in quite painful. To help me manage some of my objects lifetime dependencies, I wanted an access to a system similar to the Python WeakKeyDictionary class : Mapping class that references keys weakly. Entries in the dictionary will be > discarded when there is no longer a strong reference to the key. This can be > used to associate additional data with an object owned by other parts of an > application without adding attributes to those objects. I drafted a small 'weak_key_map' class based on boost weak_ptr, shared_ptr deleters, and a base class enabling classes to be used as keys in the weak_key_map. A small use case example is shown after, and source of weak_key_map & co are attached. I was wandering if someone had experience to share about a similar system ? For a first draft, it already serves me well - but, I'm not very happy with to "pollute" keys with the base class 'enable_master_ptr'... Any idea to improve all this ? Best regards, Nicolas. int Master_count = 0; class Master : public mgd::enable_master_ptr<Master> { public: Master() { Master_count++; } ~Master() { Master_count--; } }; int Dependent_count = 0; class Dependent : boost::noncopyable { public: Dependent() { Dependent_count++; } ~Dependent() { Dependent_count--; } }; BOOST_AUTO_TEST_CASE( test_weak_key_map_lifeTime ) { typedef boost::shared_ptr<Dependent> value_t; typedef mgd::weak_key_map<Master, value_t> map_t; map_t map; { Master master1; BOOST_CHECK( !map[&master1] ); map[&master1] = value_t( new Dependent ); BOOST_CHECK( map[&master1] ); { Master master2; map[&master2] = value_t( new Dependent ); BOOST_REQUIRE_EQUAL( Master_count, 2 ); BOOST_REQUIRE_EQUAL( Dependent_count, 2 ); } map[&master1] = value_t( new Dependent ); BOOST_REQUIRE_EQUAL( Master_count, 1 ); BOOST_REQUIRE_EQUAL( Dependent_count, 1 ); map.clear(); BOOST_REQUIRE_EQUAL( Master_count, 1 ); BOOST_REQUIRE_EQUAL( Dependent_count, 0 ); } BOOST_REQUIRE_EQUAL( Master_count, 0 ); BOOST_REQUIRE_EQUAL( Dependent_count, 0 ); }

4 6

Need advice on std::queue syncronization using boost::mutex - maybe a bug in pthread?
by Ilya Kalujny 13 Dec '08

13 Dec '08

Hello All! I`d like to ask for your kind advice regarding boost::mutex behaviour. I dont see what i`m doing wrong here. The issue is that at some point a mutex used to syncronize access to std::queue becomes locked on it's own, despite being explicitly unlocked before. I can repeat this more or less consistently. I triple checked the logic behind code and it seems correct to me. Here is the code and some explanations (i build and test under windows): Class itself: #pragma once #include <queue> // simple std::queue based boost::mutex syncronized queue template <typename T> class SyncedQueue : boost::noncopyable { private: std::queue<T> queue; // this is intended to be locked when queue is empty boost::mutex emptyIndicator; //this is intended to be locked when queue is being modified boost::mutex accessGuard; public: SyncedQueue(const SyncedQueue<T> &) { //no copy constructor since we got mutexes } SyncedQueue() { // Queue is empty at start emptyIndicator.lock(); } bool push ( T object ) { accessGuard.lock(); queue.push(object); // if someone has been waiting for data to become available in queue - let them go on emptyIndicator.unlock(); accessGuard.unlock(); return true; } bool pop ( T& object ) { // See if data is available, wait to aquire lock otherwise emptyIndicator.lock(); // OK, somethings in the queue now, we can go on accessGuard.lock(); object = queue.front(); queue.pop(); // If there is anything left in the queue - release emptyIndicator to notify other poppers that they can go on if (queue.size() > 0) { emptyIndicator.unlock(); } accessGuard.unlock(); return true; } }; Here is the test Code: #include "stdafx.h" #include <string> #include <iostream> #include <boost/thread.hpp> #include <boost/shared_ptr.hpp> #include <include/threadpool.hpp> #include "SyncedQueue.h" // global variable for the queue SyncedQueue< boost::shared_ptr < std::string > > syncedQueue; void testWriteQueue() { for (int i = 0; i < 100; i++) { char szBuff[128]; boost::shared_ptr< std::string > msgPtr; std::string tmpString = "Message"; tmpString += itoa(i,szBuff, 10); msgPtr.reset(new std::string(tmpString)); syncedQueue.push(msgPtr); std::cout << "Sent " << msgPtr->c_str() << std::endl; } // After this thread completes, reader thread sometimes deadlocks! std::cout << "Sent all" << std::endl; } void testReadQueue() { int recievedmessnum = 0; while(recievedmessnum != 100) { boost::shared_ptr< std::string > recievedMsgPtr; // After this writer thread completes, it sometimes sometimes deadlocks trying to aqurie emptyIndicator! syncedQueue.pop(recievedMsgPtr); std::cout << "Recieved " << recievedMsgPtr->c_str() << std::endl; recievedmessnum++; } std::cout << "Recieved all" << std::endl; } int main(int argc, char** argv) { using namespace boost::threadpool; pool tp(2); tp.schedule(&testWriteQueue); tp.schedule(&testReadQueue); tp.wait(); std::cout << "Test complete" << std::endl; } Thanks in advance, Ilya.

2 2

[non Boost] Template troubles.
by Robert Jones 12 Dec '08

12 Dec '08

Ok, first off, this is not explicitly about Boost, which I know is against the Boost guidelines, but I hope you'll all forgive me. Indirectly it is through trying to use Boost that i've bumped into this. A little code snippet... #include <cstddef> template < typename T, std :: size_t sz > struct Block { typedef T type[ sz ][ sz ]; }; template < typename T > void assign( T & assignee, const T & value ); template < typename T, std :: size_t sz > void assign( T ( & assignee )[ sz ], const T ( & value )[ sz ] ); int main( ) { Block< int, 16 > :: type a; const Block< int, 16 > :: type b = { }; assign( a, b ); } This compiles under Gcc & Comeau, but MS VisStudio reckons the call to assign in main is ambiguous. Any thoughts? Also, if I put all the template declarations in an anonymous namespace, Comeau fails to compile, while Gcc is still ok! Have we encountered this before, and is there a known work around? Thanks. - Rob.

3 6

Thread and exception
by Janne Kätevä 12 Dec '08

12 Dec '08

Hi I have noticed that on Ubuntu my code that uses Boost Threads works fine when I throw exceptions (for example strings) and catch them in the same thread. But this doesn't seem to work on Windows XP with Mingw gcc 3.4.5. If I throw a exception in thread, the program crashes. Is there some known problem with Boost Thread and Mingw? I'm using Boost 1.37. Simple example: #include <exception> #include <boost/thread/thread.hpp> using namespace std; class callable { public: void run() { try { cout << "Throwing" << endl; throw string("error"); } catch(string &e) { cout << "Error: " << e << endl; } } void operator()() { this->run(); } }; int main() { callable c; boost::thread thrd(boost::ref(c)); thrd.join(); return 0; } Janne

2 1

handle different endian
by boost001 12 Dec '08

12 Dec '08

Does Boost have method to do endian swap, like those ntohl and htonl? -- View this message in context: http://www.nabble.com/handle-different-endian-tp20979512p20979512.html Sent from the Boost - Users mailing list archive at Nabble.com.

2 1

[program_options] word-wrapping broken in presence of default arguments
by Peter Simons 12 Dec '08

12 Dec '08

Hi, in Boost 1.37.0, this program #include <iostream> #include <string> #include <boost/program_options.hpp> int main(int argc, char * argv[]) { using namespace std; using namespace boost::program_options; options_description cmdline_options("Supported options"); cmdline_options.add_options() ("help", "this is a sufficiently long text to require word-wrapping") ("prefix", value<string>()->default_value("/h/proj/tmp/dispatch"), "root path of the dispatch installation") ; cerr << cmdline_options << endl; return 0; } displays a usage message that looks weird: $ g++ foo.cpp -lboost_program_options.a && ./a.out | Supported options: | --help this is a sufficiently long text to requ | ire word-wrapping | --prefix arg (=/h/proj/tmp/dispatch) root path of the dispatch installation It appears that the word-wrapping algorithm can't handle the default argument properly. Is that a known problem? Can I work around that somehow? I also wonder whether it's possible to format the help string such that it's printed in the *next line*, like this: | --prefix arg (=/ridiculously/long/path/that/leaves/no/room/on/right/side) | root path of the dispatch installation I tried adding a '\n' at the beginning of the help string, but that didn't have the desired effect. Is there any way to accomplish this? Take care, Peter

1 0

[Serialization] Confusing problem serializing a vector of pointers to a base class
by Martin Weinberg 12 Dec '08

12 Dec '08

I'm struggling debugging a problem with recent versions >1.35. I have a huge code with a boost-serializaton-based persistence system. In short, all "persistent" classes derive from a base class. The code keeps track of the instances by a vector to pointers to the base class. Starting with version 1.36, saving the archive results in the following run-time message: /usr/local/boost_1_37_0/include/boost-1_37/boost/archive/impl/archive_pointer_oserializer.ipp:64: static const boost::archive::detail::basic_pointer_oserializer* boost::archive::detail::archive_pointer_oserializer<Archive>::find(const boost::serialization::extended_type_info&) [with Archive = boost::archive::polymorphic_oarchive]: Assertion `it != boost::serialization::singleton< oserializer_map<Archive> >::get_const_instance().end()' failed. I would be good, I know, to post a snippet that produces the error. Unfortunately, I've tried unsuccessfully for some time to make this occur in a simple test code with similar features to the main code. Can someone give me any pointers that would help me debug this? After a >3 days of struggle, I'm at a loss. Again, there are no problems with 1.35. I'm not suggesting that the error is not of my own making but maybe this is a clue. TIA!

1 0