Hi .. have just started using the threads and sockets parts of the library, it seems exactly what I need! I just had a comment about InetHostAddress, the docs say that the constructor, when called with no arguments will return the equivalent of an address for gethostbyname(), but in fact it returns an address for localhost (127.0.0.1).
Which is it really supposed to be? I would make my vote for the gethostbyname() version.
Anyhow - small detail, keep up the good work!
Scott
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The gethostbyname() behavior was depreciated because it required
the "resolver" to determine the final IP address, and this made for
some problems until very recently, when I found what was wrong
with the way MutexCounter was being used in protecting threaded
hostname resolving. This also touches upon the fact that I would like to write a new and thread-aware name resolver as part of CC++ in the future.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi .. have just started using the threads and sockets parts of the library, it seems exactly what I need! I just had a comment about InetHostAddress, the docs say that the constructor, when called with no arguments will return the equivalent of an address for gethostbyname(), but in fact it returns an address for localhost (127.0.0.1).
Which is it really supposed to be? I would make my vote for the gethostbyname() version.
Anyhow - small detail, keep up the good work!
Scott
The gethostbyname() behavior was depreciated because it required
the "resolver" to determine the final IP address, and this made for
some problems until very recently, when I found what was wrong
with the way MutexCounter was being used in protecting threaded
hostname resolving. This also touches upon the fact that I would like to write a new and thread-aware name resolver as part of CC++ in the future.