How can i create a thread that executes a function (void) in a class, cause

void foo() {}

int main()
{
std::thread first (foo); 
}

works

but
 

struct TTCPServer
{
void foo() {}
void CreateThread()
{
std::thread first (foo); 
}
};

doesnt even compile

#include <functional>
#include <thread>

struct TTCPServer {
    void foo() {}
    void CreateThread() {
        std::thread first(std::bind(&TTCPServer::foo, this)); 
    }
};

int main() {};

https://wandbox.org/permlink/6IODSGQnzTtm5QhU

"this" is always passed as an implicit argument of the member method. You must bind all arguments of the member method.

yeah i just went here to write the same thing i figoured that out myself thanks man

listen_and_accept_finished = false;

std::thread ListenThread(&TTCPWindowLayerServer::ListenAndAccept, this);

however using your code or mine makes my app to crash

theres an int i increment each time thread loop executes

void ListenAndAccept()
{
	while (!listen_and_accept_finished)
	{
		Port = Port + 1;
		continue;
    }
}

and it just crashes after few iterations

i dont even use int Port; anywhere else except during class constructor to define it as 0

listen_and_accept_finished isnt used anywhere else than in this loop too

i get

Fatal signal 6 (SIGABRT)
 

it may seem that android doesnt like threads...

30 minutes ago, Cat's machete said:

and it just crashes after few iterations

You only invoke CreateThread once, I suppose? I am not really into <thread>, but shouldn't listen_and_accept_finished (and Port) be volatile, since they will be modified outside the thread? Though in any case, I am not sure why it would crash.

#include <functional>
#include <iostream>
#include <thread>

struct TTCPServer {
    volatile bool listen_and_accept_finished = false;
    volatile int port = 0;
    
    void ListenAndAccept() {
       while (!listen_and_accept_finished && port < 10) {
           std::cout << port++ << std::endl;
       }
    }
    
    std::thread CreateThread() {
        return std::thread(std::bind(&TTCPServer::ListenAndAccept, this)); 
    }
};

int main() {
    TTCPServer server;
    server.CreateThread().join();
};

https://wandbox.org/permlink/A8cZoSbv6wM9BST8

funniest thing is whenever i add ListenThread.join(); and create exit condition so thread actually quits it doesnt crash anything.

5 minutes ago, Cat's machete said:

funniest thing is whenever i add ListenThread.join(); and create exit condition so thread actually quits it doesnt crash anything.

As I understand you correctly, you execute something like my code above without invoking "join" on the "std::thread"? In this case your main thread will finish, destroy the TTCPServer on the stack which causes the captured "this" pointer of your std::thread to become invalid, resulting in undefined behavior.

this is why i do this:

TTCPWindowLayerServer * srvtcp = new TTCPWindowLayerServer();
    srvtcp->CreateServer(0);

i dont want to call join cause i don't want the main thread to be paused at all,

however it may seem that android automatically crashes my app, since i think it thinks the UI Thread is being suspended, thus how is this even possible, when i spawn a thread so it shouldnt matter from which place i spawn it, it should independly even when im creating server class in that ui thread, but if it is so, then i just grab my pc and throw it into river.

looks like you cant stall ui thread with some standard function even for 20 seconds, but you cant stall it with a thread for even a microsecond., and my app base is always dependnt on ui thread since i call onTap(x, y) from java to execute cpp code.....

either i thro pc and phones to the river or make a bypass by using join and somehow proceed with stalled threads. giving up seems easier

27 minutes ago, Cat's machete said:

i dont want to call join cause i don't want the main thread to be paused at all,

I know, but in the end you want your application including all its threads to be terminated properly. I just added it to have a correct example. 

i have read cpp reference more carefully and found that detach does not kill the thread but makes it independent from creator thread, so this is my saint graal

Detaches the thread represented by the object from the calling thread, allowing them to execute independently from each other.

Both threads continue without blocking nor synchronizing in any way. Note that when either one ends execution, its resources are released.

After a call to this function, the thread object becomes non-joinable and can be destroyed safely.

jeez i almost threw all my phones down the river ;p

It might work at the moment, but as soon as your thread does something interesting, it will likely need to communicate with other parts of your program.

Depending on how that is implemented, you could re-introduce the crashes.