I'm not familiar with the asio library, but while looking at the headers I found that while
asio::ip::address_v4 and asio::ip::address_v6 are sizes I would expect, asio::ip::address was overly large. Taking a look at the structure it became clear why.
// The type of the address.
enum { ipv4, ipv6 } type_;
// The underlying IPv4 address.
asio::ip::address_v4 ipv4_address_;
// The underlying IPv6 address.
asio::ip::address_v6 ipv6_address_;
};
However looking at the code, it appears as though it was almost~ made into a tagged union as I might have expected. So now I'm curious, is this intended or not?
For reference, I believe a lot of implementations tackling this problem of v4 vs v6 addressing use the backwards compatibility of v6 with v4, making space for a v6 address. Which would look like this:
// The type of the address.
enum { ipv4, ipv6 } type_;
union {
// The underlying IPv4 address.
asio::ip::address_v4 ipv4_address_;
// The underlying IPv6 address.
asio::ip::address_v6 ipv6_address_;
};
};
I'm not familiar with the asio library, but while looking at the headers I found that while
asio::ip::address_v4andasio::ip::address_v6are sizes I would expect,asio::ip::addresswas overly large. Taking a look at the structure it became clear why.However looking at the code, it appears as though it was almost~ made into a tagged union as I might have expected. So now I'm curious, is this intended or not?
For reference, I believe a lot of implementations tackling this problem of v4 vs v6 addressing use the backwards compatibility of v6 with v4, making space for a v6 address. Which would look like this: