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

Converting an existing thread to use boost.thread
by Sean Farrow 18 Apr '09

18 Apr '09

Hi; I am in the process of converting an existing thread function originally called using BeginThread to use boost.thread. I have a coupple of questions: 1. How would I go about returning to the existing thread, I use windows event handles and when one is signaled the thread ends, can I still use a while loop to do this, such as: Do { Code While(returnFromThread !=true); 2. Does boost::thread allow me the create mutex's and does it inherit windows mutex handles. 3. Can I tell a thread to run as soon as it starts or do I have to use the call boost.join. Any help apreciated. Cheers San. __________ Information from ESET NOD32 Antivirus, version of virus signature database 4018 (20090418) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

1 0

Exposing std::pair to Python
by A B 18 Apr '09

18 Apr '09

Hi, I am wondering if anyone has a working example of exposing std::pair as a Python tuple or list. Technically, I need to expose a vector of tuples and the following works class_<std::vector<std::pair<std::string, double> > >("VectorPair") .def(vector_indexing_suite<std::vector<std::pair<std::string, double> > >()) ; but I am not sure how then to expose the std::pair. I am guessing I should use boost/python/tuple.hpp or list.hpp but can't figure out the syntax. Thanks in advance.

2 2

[Thread] assertion `!pthread_mutex_lock(&m)' running threaded test
by Rush Manbert 17 Apr '09

17 Apr '09

I have this test program: ------------------------------------------- #include <iostream> #include <vector> #include <boost/thread.hpp> class TestThread { size_t m_loopCount; int m_serverPort; public: TestThread (size_t loopCount) : m_loopCount (loopCount > 0 ? loopCount : 1) , m_serverPort (9090) { return; } void operator() (void) { for (size_t loopCount = 0; loopCount < m_loopCount; ++loopCount) { // Do the same thing the socket open code does char port[6]; sprintf(port, "%d", m_serverPort); char buf0[512]; sprintf (buf0, "%s %zd", "Our loop cont is: " , loopCount); char buf1[793]; sprintf (buf1, "Now the loop count is: %zd", loopCount); // boost::this_thread::yield(); } } }; int main (int argc, char * argv[]) { unsigned int threadLoopCount = 20000; unsigned int threadCount = 2500; // Thread storage std::vector<boost::thread *> threadVec; for (size_t i = 0; i < 1; ++i) { std::cout << i << ": Spawn " << threadCount << " threads with loop count = " << threadLoopCount << std::endl; for (size_t i = 0; i < threadCount; ++i) { TestThread theThread(threadLoopCount); threadVec.push_back (new boost::thread (theThread)); } while (false) <<<-----------------------------------------This block of code disabled { threadVec.at(0)->join(); delete threadVec.at(0); threadVec.erase(threadVec.begin()); TestThread theThread(threadLoopCount); threadVec.push_back (new boost::thread (theThread)); } for (size_t i = 0; i < threadVec.size(); ++i) { threadVec.at(i)->join(); <<<<-----------------------------Error location 1 delete threadVec.at(i); <<<<-----------------------------Error location 2 } threadVec.clear(); std::cout << "Done" << std::endl; } } ------------------------------------------- I haven't edited it to remove disabled code. Note the while(false) which disables the block of code that was starting a new thread as soon as one completed. What the thread code actually does is designed to reveal a different problem. The for loop that only executes once was a failed attempt to make the desired error happen more often. If I run this program enough times in the Xcode debugger, I eventually see the error: ./boost/thread/pthread/mutex.hpp:50: failed assertion `! pthread_mutex_lock(&m)' In the latest case, this happened at the line I have labeled as "Error location 1", but I have also seen this at the line labeled as "Error location 2". I have seen other threads regarding similar errors with boost threads, but nothing says that this was a bug that has been fixed, or that there is something I should do to avoid the error. I'm also wondering if I have misunderstood something about how to use the threads code. I am running Boost 1.36.0 on OSX 10.5.6 with Xcode 3.1.2. Does this look like pilot error, or is it a bug? - Rush

2 1

[program_options] Multitoken and positional options; assertion failure
by Gevorg Voskanyan 17 Apr '09

17 Apr '09

I was playing with program_options in svn trunk after recent fixes for multitoken options and hit an assertion failure with the attached example. The example takes two options - one multitoken and one positional, and simply outputs provided values. The two invocations below work OK: $ bin/gcc-4.2.2/debug/multitoken_positional some_file -m token1 token2 File: some_file Multitoken: token1 token2 $ bin/gcc-4.2.2/debug/multitoken_positional -m token1 token2 --file some_file File: some_file Multitoken: token1 token2 While experimenting with this one asserts: $ bin/gcc-4.2.2/debug/multitoken_positional -m token1 token2 -- some_file multitoken_positional: ../../../../../svn_boost/trunk/libs/program_options/src/cmdline.cpp:295: std::vector<boost::program_options::basic_option<char>, std::allocator<boost::program_options::basic_option<char> > > boost::program_options::detail::cmdline::run(): Assertion `opt2.original_tokens.size() == 1' failed. Aborted Should an exception be thrown instead, or this is a use-case worth to support? Thanks, Gevorg

2 2

[boost-users][bind, lambda, ...] binding unused actual parameter
by Igor R 16 Apr '09

16 Apr '09

Hello, Is it possible somehow to make a binder that stores "unexpected" argument? Motivation: I have to create & pass a callback handler from within intusively ref-counted object (MS-ATL) to an outer asynchronous subsystem. If the object were shared-ptr enabled, I'd do this as usually: ThisObj::handler() { //... } ThisObj::doSomething() { asyncSubsystem_->doSomething(&ThisObj::handler, shared_from_this()); } However, in my case I have to do something like this: asyncSubsystem_->doSomething(&ThisObj::handler, this, mySmartPtr); // store someOtherSmartPtr in the functor, just to ensure "this" won't die before the handler is invoked Is it possible with bind, lambda or some other library? Thanks.

3 8

[filesystem] doc bug
by Michael Fawcett 16 Apr '09

16 Apr '09

A co-worker of mine who usually programs in C# ran across this bug in the filesystem Two Minute Tutorial located here: http://www.boost.org/doc/libs/1_38_0/libs/filesystem/doc/index.htm#tutorial #include "boost/filesystem.hpp" // includes all needed Boost.Filesystem declarations #include <iostream> // for std::cout using boost::filesystem; // for ease of tutorial presentation; // a namespace alias is preferred practice in real code Should be: #include "boost/filesystem.hpp" // includes all needed Boost.Filesystem declarations #include <iostream> // for std::cout using namespace boost::filesystem; // for ease of tutorial presentation; // a namespace alias is preferred practice in real code Note the using statement. --Michael Fawcett

1 0

Re: [Boost-users] Multiple Multitokens
by David Doria 16 Apr '09

16 Apr '09

Volodya, So was my example code way off? Ie. is the short answer that program_options can't take --list a.txt b.txt --list c.txt d.txt and give me 2 vector<string>'s, one containing a.txt b.txt and the other containing c.txt d.txt? Thanks, David

2 1

Covariant return type, method hiding, and shared_ptr advice
by Dominique Devienne 16 Apr '09

16 Apr '09

(follow up to the "How to obtain shared_ptr<Derived> from shared_ptr<Base>?" post) class Ident { ... }; class Object { Ident* ident() { return ident_.get(); } const Ident* ident() const { return ident_.get(); } shared_ptr<Ident> ident_ptr() { return ident_; } private: shared_ptr<Ident> ident_; }; class VehicleIdent : public Ident { /* Vehicle-specific ident members */ } class Vehicle : public Object { // covariant return type VehicleIdent* ident() { return polymorphic_downcast<VehicleIdent*>(Object::ident()); } const VehicleIdent* ident() const { /* same as above */ } }; In the class hierarchy above, I return both raw and shared_ptr of an object's identity, something that opens up the possibility for bugs were the raw pointers is deleted or stuffed into another "unrelated" smart pointers. But on the other hand, when I'm dealing with a Vehicle (corrected spelling ;) instead of an Object, I'd like to get it's ident with the proper type (VehicleIdent), to access the vehicule-specific identity naturally (those methods are not shown here). So I used covariant return type, which AFAIK works only for raw pointers. If I were to remove the raw pointer accessors, I'd have to do either: class Object { shared_ptr<Ident> ident() { return ident_; } }; class Vehicle : public Object { shared_ptr<VehicleIdent> vehicule_ident() { ... } }; i.e. have a new method each time, which is less uniform, or: class Object { shared_ptr<Ident> ident() { return ident_; } }; class Vehicle : public Object { shared_ptr<VehicleIdent> ident() { ... } }; which hides the base ident() in the derive classes. What is the best alternative? Or is there a better way to deal with this? Thanks, --DD PS: is returning a const shared_ptr<T>& is better/worse than a copy?

3 7

Re: [Boost-users] Multiple Multitokens
by David Doria 16 Apr '09

16 Apr '09

Volodya, thanks for the help thus far, I think I am close to getting it to work. According to the post you referred me to, multiple of the same parameter are not collapsed, ie --list a.txt b.txt --list c.txt d.txt Should give me access to the two separate lists. I tried declaring the parameter as usual: ("list", po::value<vector<string> >()->multitoken(), "Lists.") And then I thought it may be the .count property? cout << "There are " << vm.count("list") << " lists." << endl; But there is only 1 list. The idea was to do this: vector<vector<string> > lists; for(unsigned int list = 0; list < vm.count("list"); list++) { vector<string> l = vm["list"].as<vector<string> >(); lists.push_back(l); for(unsigned int item = 0; item < lists[list].size(); item++) cout << "List: " << list << " Item: " << item << " " << lists[list][item] << endl; } Clearly I am still missing the part about accessing the separated "list" params. Can you see the problem here? Thanks, David > > David Doria wrote: > > > I want to do something like this: > > --NumLists 2 --List0 a.txt b.txt --List1 c.txt d.txt > > > > vector<vector<string> > Lists(2); > > > > po::options_description desc("Allowed options"); > > desc.add_options() > > ("help", "produce help message") > > ("List0", po::value<vector<string> > >(&Lists[0])->multitoken(), > > "List0.") > > ("List1", po::value<vector<string> > >(&Lists[1])->multitoken(), > > "List1.") > > ; > > > > But if I wanted to handle --NumLists 10, I would have to manually add > List0, > > List1, ... List10 as parameters. That seems a bit silly, but maybe this > is a > > very odd usage? > > Well, it's somewhat odd :-) > > > Please let me know if you can think of a better way to > > handle this. > > Well, as a remark, your command line interface will make users cry: > > - Do you really want users to type uppercase letters? (Use can use > case-insensitive mode, of course, and allow any spelling, but upper > case in your example seems strange. > - Do you really want users to count lists and pass 0, 1, 2, etc explicitly? > - Why do you need explicit specification of the number of lists? > > I'd use: > > --list a.txt b.txt --list c.txt d.txt > > You might find the recent thread useful for handling such command lines: > > http://permalink.gmane.org/gmane.comp.lib.boost.user/46405 > > - Volodya > > >

2 2

Re: [Boost-users] default argument and call trait const_reference
by Hicham Mouline 16 Apr '09

16 Apr '09

>I apologize, I didn't replace all names to make code more readable... >It was just P ... that was P's ctor... >It's Get, not GetSpot >x.template Get<P,P>( 5 ); >I've added to default argument to the out-of-class definition as well >and then it works... >does it make any sense? >H I put the code here: http://codepad.org/6tLNKGvO 1) g++3.4 complains about putting the default parameters in the declaration and the definition of GetSpot<> 2) VS2005 compiles it fine. As I said in my previous email, when the default parameter "Interp()" is not put in the definition of GetSpot<> debugging shows that "i" has not been constructed properly. When I add "Interp()" to the definition also, debugs works fine. In Release, the same behaviour is observed. Regards,

1 0