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

plans for boost::sockets library?
by Oliver.Kowalke＠infineon.com 27 Oct '05

27 Oct '05

Hello, is a library for boost::sockets planed? Regards, Oliver

3 2

Re: [Boost-users] multi-inheritance from elements of mpl::vector? ==> inherit_scattered ( for Barton & Nackmann trick)
by Foster, Gareth 27 Oct '05

27 Oct '05

> no reply - so I found a solution by myself (used for the Barton & > Nackmann trick)! > cu, > Oliver > Is there a page somewhere that describes the trick, just out of interest like. Gaz

1 0

Compile boost_wserialization.dll error in CVS of branch RC_1_33_0
by shenhuifeng 27 Oct '05

27 Oct '05

1 0

[Serialization] Fighting code bloat...
by Mats Eklund 27 Oct '05

27 Oct '05

4 3

Re: [Boost-users] Extended Thread object
by Phil Endecott 26 Oct '05

26 Oct '05

>>The actual application is a sort of daemon; a main loop accepts tcp >>connections, and creates a new thread to handle each one. It normally >>wants to "fire and forget" these threads, and I imagine it creating them >>with new() and then letting them dangle, until they eventually terminate >>and delete themselves. > > > I may be missing something here, but if thread lifetime and object > lifetime are not tied, why not create the object on the stack (as part > of an accept() loop, using the tcp connection example). The stack > based object will be destroied each loop, but the thread itself will > continue to exist until it ends. Yes, that's true. I suppose I'm thinking this way because I'm also imagining that I can subclass this new Thread class to add state, e.g. class DaemonThread: public Thread { private: ... per-connection state ... public: DaemonThread(int connection_fd); }; void mainloop() { while(1) { int fd = accept_connection_on_socket(); DaemonThread* handler = new DaemonThread(fd); } } If instead I put the state in another object that's created within the thread's initial function then I can afford for the actual thread object to expire immediately. There must be lots of ways to do this sort of thing. > You could also use boost::call_once to "fire and forget" I think I know what call_once() does but I don't see how it helps. Can you elaborate? Cheers, --Phil.

2 2

"Different" use of shared_ptr/weak_ptr
by Goran Pusic 26 Oct '05

26 Oct '05

Hi all! I am trying to use boost smart pointers for some multithreaded work in the following way: 1. I use shared_ptr to wrap stuff in thread 1 2. I create weak_ptr-s in thread 1 and pass them to thread 2 3. in thread 2, I lock my weak_ptr-s and use stuff I get from there 4. in thread 1 I may destroy my shared_ptr 5. next time I want to lock my weak_ptr, I get NULL and can't use stuff Basically, my idea is to use weak_ptr as sort of transport mechanism between threads, but with "stuff destroyed detection". I did some tryouts and this seems to be OK. However, I'd like to get some more authorative advice :-)) Can I do that? If no, why not, or, what would you suggest? Thanks, Goran. --------------------------------- Yahoo! FareChase - Search multiple travel sites in one click.

2 1

test: using floating_point_comparison.hpp in precompiled header
by Matt Amato 26 Oct '05

26 Oct '05

I don't know if this is a bug or not, but using boost/test/floating_point_comparison.hpp in a precompiled header under VC71 on Windows yields multiply defined symbol errors for each file using it. The workaround is to not use it in a precompiled header but only in the source files where it is needed. Any ideas? Linking... stdafx.obj : error LNK2005: "struct check_is_close_t::boost::check_is_close_t boost::test_tools::`anonymous namespace'::check_is_close" (?check_is_close@?A0x5e8fa061@test_tools@boost@@3Ucheck_is_close_t@23@A) already defined in TestExample.obj ..\..\..\..\..\bin\Debug.NET\Test.exe : fatal error LNK1169: one or more multiply defined symbols found

3 2

Extended Thread object
by Phil Endecott 26 Oct '05

26 Oct '05

Dear Experts, The boost::thread documentation says: Just as the lifetime of a file may be different from the lifetime of an iostream object which represents the file, the lifetime of a thread of execution may be different from the thread object which represents the thread of execution. In particular, after a call to join(), the thread of execution will no longer exist even though the thread object continues to exist until the end of its normal lifetime. The converse is also possible; if a thread object is destroyed without join() first having been called, the thread of execution continues until its initial function completes. That's fine, but it's not what I'm looking for right now. Can anyone point me to some code - perhaps adding a layer on top of boost::thread - that ties object lifetime to thread lifetime in some way? (I'm imagining a dynamically-allocated object the deletes itself when the thread's initial function terminates, and that kills the thread if it (the object) is deleted first.) The actual application is a sort of daemon; a main loop accepts tcp connections, and creates a new thread to handle each one. It normally wants to "fire and forget" these threads, and I imagine it creating them with new() and then letting them dangle, until they eventually terminate and delete themselves. My guess is that this could be done in just a few lines of code, but there are probably lots of race conditions to worry about. Any suggestions anyone? Cheers, --Phil.

3 2

thread: condition::notify() does not require a lock - why?
by Pete Chapman 26 Oct '05

26 Oct '05

condition::wait requires that a lock is acquired prior to calling it, but condition::notify does not. The Java threading API (which in my limited experience seems similar to boost::thread) requires that a lock is acquired prior to calling Object.notify(). Is this potentially a problem? For example: scoped_lock myLock(myMutex); while (!some_variable) { // Another thread now sets some_variable = true, and // calls myCondition.notify() // then... // will this wait indefinitely? myCondition.wait(myLock); } Clearly if the other thread in this example were forced to obtain a lock on myMutex before calling myCondition.notify(), there would be no danger. In practice this is what I do anyway, but the boost:thread API doesn't force me to. Why not? Is there a potential problem if I don't? Many thanks...

2 2

bind with boost::function
by Eric Pruneau 26 Oct '05

26 Oct '05

Hi Here is my problem. I need to specify a callback function for use with OpenCV cvcam dll. I modified OpenCV to accept a boost::function1<void,IplImage*> instead of a simple void pointer to a function. The function is called by openCv on every frame of a video stream. Im trying to have the callback function member of a class e.g Class A { ... void init() { ... boost::function1<void,IplImage*> Myfunct; Myfunct = boost::bind(&A::Callback, this); cvcamSetcallback(Myfunct); // OpenCV function to set the callback } void Start() { /* tell opencv to start grabbing frames and to call Callback on every frame */ } void Callback(IplImage* img) { /* process the image */ } ... }; Its not like I want to directly call the callback function and use it like a functor. I want OpenCv to call my member function. When I try to compile this it give me: error C2091: function returns function on a C++ .net compiler. Im really confused and I dont have a clue about how to solve this. Thanks in advance Eric _________________________________________________________________ Balayez vos courriels entrants et sortants et les pièces jointes et contribuez à éliminer les virus destructeurs susceptibles dy être intégrés. http://join.msn.com/?pgmarket=fr-ca&page=features/virus Commencez dès maintenant à profiter de tous les avantages de MSN Premium et obtenez les deux premiers mois GRATUITS*.

2 1