Hi Pedro, --- Pedro Lamarão <pedro.lamarao@intersix.com.br> wrote: <snip>
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?
I was thinking more in terms of the ability to directly manipulate addresses, endpoints etc for only one type. I.e. in applications where you do not want automatic runtime support for both IPv4 and IPv6. These applications shouldn't need to check the type of an address at runtime if compile-time checking is available. However I am asking the question of whether it is valuable to retain the separate types because I don't know whether such use cases do exist, or are common enough to warrant maintaining this support.
Something like this?
template <int FamilyT, int StyleT, int ProtocolT> class socket;
Actually the template parameter would be an implementation of the Protocol concept: class Protocol { public: int family() const; int type() const; int protocol() const; ... }; This still allows the protocol to be determined at runtime, if necessary (as it is to dynamically support both IPv4 and IPv6).
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?
Yep, these last reasons are the motivation for these changes. I.e. adding compile-time type safety in dealing with socket types.
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.
Yes :) However from the user's point of view, the changes I'm planning would look more like: ip::tcp::endpoint ep(1234, "::1"); ip::tcp::socket s(io_service); s.connect(ep); Cheers, Chris