Noah Roberts wrote:
void start_new_connection() { ... boost::thread connection_thread(connection_thread_proc(l,s)); }
Originally I assumed that there would be problems with this since my thread object goes out of scope so I figure the connection_thread_proc it holds should be destroyed along with it...and with it important objects like the listener and the tcp connection. So I was working on this convoluted way to store threads and check their state...which boost doesn't support out of the box it looks like and I was going to have to add yet another wrapper to the pile...so I decided to try and see if it did indeed explode and it doesn't.
The question is, am I looking at undefined behavior that happens to work correctly or is this by design?
It works by design. The constructor of boost::thread makes a private copy of the function object and keeps it alive until its operator() returns. The boost::thread object itself is irrelevant, the function object is part of the thread state block kept by the newly spawned thread. You can use boost::bind( &Listener::run, l, s ) instead of writing a function object by hand, although I don't know how it will react to your ^ thingies. :-)