Reason why somebody would be interested in
//...
new std::thread (func,arg1,arg2);
}
is that std::thread destructor(unlike boost::thread) kills the thread. func finishes is some time.
My question is this safe in cases:
Case 1: lets say that function takes arg1, arg2 by value.
Case 2: lets say that function takes arg1, arg2 by reference-this sounds bad if you ask me, because I presume that at the end of the scope where thread is created arg1 and arg2 will be cleared by their destructors.
BTW is std::thread destructor(that is AFAIK called when func finishes) smart enough to clear all the resources used by thread? I mean if I create 1M threads(ofc not at the same time) with new and all of them finish, have I leaked anything permanently?
An std::thread object represents a thread, it is not a “real” thread, that is a concept managed by the OS.
Therefore, here you’re leaking a std::thread object because you don’t delete it. The destructor is never called.
But the thread it was representing will end when it’s instructions will end, like any thread.
If the destructor was called before the end of the instructions, for example if you would have created that object on the stack and there was a lot of things to do in this new thread, then the destructor call would have triggered std::terminate(). You need to call detach() to allow the thread to continue after the std::thread instance is destroyed.
That way, you have to explicitely say if you want or not this thread to end when the std::thread instance is destroyed : if you want it to continue, call detach(); if you want to wait for it to end, call join().
So in your case you leak memory but the thread should continue as the std::thread object lives “forever” because you lost any way to control it.