Simple TCP Listener class
Naming

I think you're naming convention is OK, it seems consistent which is the most important thing.  Some of your names could be a bit more specific:

std::function&lt; void(SOCKET) &gt; callback


callback doesn't tell me what the callback is for.  new_connection_callback might be more appropriate.

Shutdown

There's no obvious way to shutdown your server.  You just allow the object to be destroyed and hope for the best.  I'd usually add a shutdown to a class like this so that the listen thread can be shutdown cleanly.  The accept thread itself has a loop while (client == SOCKET_ERROR) which is a condition that is always true.  You may as well be saying while(1).

Startup

Since the class has no concept of state it doesn't know whether or not it's running.  This means you can't check if it's running when startup is called, so you get a strange error 'can't bind to socket' if you try to start the server on two different ports.  Usually you'd encounter this error if the port was already in use.  However, since the server port is an instance variable you get it because the SOCKET itself is already in use.

Constructor errors

This is a critical error:

if (WSAStartup(MAKEWORD(2, 2), &amp;wsa) == SOCKET_ERROR)


If you can't get a socket, your application is in trouble.  Don't just write to the log, throw an exception so that the caller is aware that there has been a problem and they can stop processing.

Callbacks

It's often useful to pass an additional piece of data into a callback method (for example a pointer to an instance of a collection to add the new socket to).  With that in mind, I'd consider adding an extra parameter (usually a void*) to the callback.  You also might want to consider typedefing the callback to make it easier to update in one place (if you decide to in the future).

Something like:

typedef std::function&lt;void(SOCKET)&gt; accept_callback;


makes the function signatures more descriptive and concise:

tcp_listener(accept_callback callback);