Boost :: asio :: ip :: tcp :: resolver :: resolve () blocks forever

Question

I am trying to create something similar to this code found in boost.asio examples.

socket.h:

class some_class { private: ... boost::asio::io_service io_service; public: some_class() { /* This stuff isn't used in the example... ...but it doesn't change anything... */ io_service.run(); } }; 

socket.cpp:

 using boost::asio::ip::tcp; bool some_class::connect(char* host, char* port) { printf("Resolving hostname...\n"); /* Resolve hostname. */ tcp::resolver resolver(io_service); tcp::resolver::query query(tcp::v4(), host, port); tcp::resolver::iterator iterator = resolver.resolve(query); printf("Connecting to %s:%s... ", host, port); /* Connect to resolved hosts. */ sock->connect(*iterator); return true; } 

g ++ creates this without any errors, but the code never misses the call to resolver.resolve ().
I tried both "127.0.0.1" and "localhost" for the host and "80" for the port. (don't think it matters, but apache2 is up and running)

When I ctrl + c from my application, it obviously ends, but it displays "Connect to a string" just before it executes.

I plan to create an example myself and see if the same problem arises, and, of course, post the results here. Has anyone encountered this problem or knows what might cause this behavior?

Editing:
The example runs just fine ... I have some debugging, I suppose.

second edit:
I do not understand, the only thing that can be different is the host / port.
The example uses char * argv [], and I use:

 char host[] = "localhost"; char port[] = "80"; 

third edit:
it really seems blocking when connected, forgot fflush (stdout). then this should be a problem with the socket. going to do some more tests.

fourth edit:
stupid, he did not block at all! I just relied too much on console output.

Answer 1

Probably a call block to connect after printf.

stdout is buffered by line by default, and since you do not have \ n at the end of the line printf, you will not see its output. When you kill the program, the buffer is cleared, so you see a message.