Christopher Kohlhoff wrote:
- Is it worth keeping separate ipv4 and ipv6 namespaces? Some applications may want to explicitly specify one or the other.
You can consider it from the operating system upwards. In modern Windows and Unixes best practice is to use getaddrinfo and getnameinfo for translation to and from network and human address representation, and these calls work portably with IPv4 and IPv6 addresses today. Every function call for whom the network family is relevant receives this information at runtime, and not at compile time. (Like, say, wprintf is hardwired to the wchar_t character type.) So separating IPv4 and IPv6 into almost two separate libraries is not something the operating system forces or suggests. What kind of usability does it provide?
- How does this fit with Giovanni Deretta's suggestion of separate types for each protocol's socket? Does it mean having an asio::ip::tcp::socket type, for example? The issue is that the concrete protocol (IPv4 or IPv6) needs to be known before the socket object is opened.
Something like this? template <int FamilyT, int StyleT, int ProtocolT> class socket; It provides static knowledge of "family" and "style" that could be useful if you want to do some magic with the endless amount of flags and parameters for getsockopt and setsockopt specific to each, and gives us a neat default constructor. Otherwise, where would this information make a difference at compile time? Maybe validating generic address objects passed to connect or bind or whatever, or making getsockname and getpeername easier to use? Me, being a big fan of IOStreams, dismissed quickly this approach while trying to work with: // Lots of static structs to wrap all those ints template <typename CharT, typename TraitsT, typename FamilyT, typename StyleT, typename ProtocolT> class basic_socketstream; It's just too ugly. -- Pedro Lamarão Desenvolvimento Intersix Technologies S.A. SP: (55 11 3803-9300) RJ: (55 21 3852-3240) www.intersix.com.br Your Security is our Business