Updated draft of three-class IP address proposal

[Christopher Kohlhoff]

Hi,

I have attached an updated draft of the three-class IP address proposal.
This revision incorporates some of the suggestions and ideas from
Bristol into the wording. Now that we can see what these changes look
like in terms of code and standardese, we can have a discussion on their
merits.

A reference implementation of sorts can be found at:

<https://github.com/chriskohlhoff/ip-address>

Cheers,
Chris

[Arash Partow]

On Thu, Apr 17, 2014, Christopher Kohlhoff wrote:
> I have attached an updated draft of the three-class IP address proposal.
> This revision incorporates some of the suggestions and ideas from
> Bristol into the wording. Now that we can see what these changes look
> like in terms of code and standardese, we can have a discussion on their
> merits.
>
>

That's some pretty awesome proposing you've got going there - good work!

One quick comment though, unless I've missed something would it be
reasonable to have a free function form of to_string in the std
namespace (or another appropriate one) rather than just methods. It
would make writing generic code somewhat easier, though I guess one
could simply introduce it into a local namespace as needed.



Arash

[Christopher Kohlhoff]

On Thu, Apr 17, 2014, at 02:31 PM, Arash Partow wrote:
> One quick comment though, unless I've missed something would it be
> reasonable to have a free function form of to_string in the std
> namespace (or another appropriate one) rather than just methods. It
> would make writing generic code somewhat easier, though I guess one
> could simply introduce it into a local namespace as needed.

I did consider this a while ago and I have no technical objections, but
I was unable to find any precedent in the standard. E.g. the existing
std::to_string() free functions are for numeric conversions only. If the
intention is it for be something generic, then in my opinion it needs
wider discussion and blessing from LWG or LEWG.

Cheers,
Chris

[Glyn Matthews]

I also considered it for the URI proposal, but I went with a member function because std::bitset provides to_string in this way.

Regards,

Glyn

[stackm...@hotmail.com]

Is there a specific reason why address is not a union of address_v4 and address_v6? And why is there no way to access the underlying platform specific address objects?

[Dean Michael Berris]

Thanks for this Chris!

I've a few questions, hoping you can clarify:

- Have you considered using a string_view instead of the overloads for
string, const char*?
- Are you flexible on whether to remove the "is_class_{a,b,c}" members
on address_v4 and just opt for returning the subnet length?
- address_v4 looks like an address_range_v4 though if you're hoping to
answer the question of what the bitmask is. I would suggest keeping an
address_v4 a pure address value type, and flesh out instead an
address_range_v4 that gives the answers to questions like: what is the
address mask, what is the prefix length, what is the broadcast
address, network address, how many addresses are there in this range,
etc.
- I see an ostream<< overload but not an ostream>> overload -- is this
by design or just an inadvertent oversight?

Looking forward to further discussion on this and some of the
algorithms that can be implemented on top of these types.

> --
> You received this message because you are subscribed to the Google Groups "SG4 - Networking" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to networking+...@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/networking/.
> For more options, visit https://groups.google.com/a/isocpp.org/d/optout.

[chris_kohlhoff]

On Monday, May 5, 2014 12:34:45 AM UTC+10, Stack Machine wrote:

Is there a specific reason why address is not a union of address_v4 and address_v6?

That's effectively what it is, i.e. a discriminated union. Whether it uses a union internally is an implementation detail.

 

And why is there no way to access the underlying platform specific address objects?

IP addresses don't have a platform-specific representation in a meaningful sense. What they do have is a standard representation, and that's what to_bytes() gives you.

Cheers,

Chris

[chris_kohlhoff]

On Tuesday, May 6, 2014 12:20:58 PM UTC+10, Dean Michael Berris wrote:

Thanks for this Chris!

I've a few questions, hoping you can clarify:

- Have you considered using a string_view instead of the overloads for
string, const char*?

There are multiple approaches to string handling in the standard library and the forthcoming technical specifications. I'm leaving this alone to allow the LWG to decide which approach they prefer.

 

- Are you flexible on whether to remove the "is_class_{a,b,c}" members
on address_v4 and just opt for returning the subnet length?

The is_class_*() functions are provided because the equivalent IN_CLASS* macros are part of BSD sockets. Particularly with the availability constexpr, people shouldn't have a need to reach for those macros any more.

On the other hand, the subnet length is not something that can be reliably determined from an address alone. You need to have the subnet length explicitly specified or be able to look up the address's subnet in the routing table. For this reason I have also removed the netmask() function from ip::address_v4 in this revision.

And I agree that this is indeed the job of a separate class like you say:

 

- address_v4 looks like an address_range_v4 though if you're hoping to
answer the question of what the bitmask is. I would suggest keeping an
address_v4 a pure address value type, and flesh out instead an
address_range_v4 that gives the answers to questions like: what is the
address mask, what is the prefix length, what is the broadcast
address, network address, how many addresses are there in this range,
etc.

Whether that's an address range, cidr_address or whatever, is a discussion we should have. However, it's deliberately out-of-scope for this proposal in the interests of getting something standardised.

 

- I see an ostream<< overload but not an ostream>> overload -- is this
by design or just an inadvertent oversight?

It's a deliberate omission as I think it's difficult to specify operator>> correctly for IP addresses. I'd rather not provide it than try to provide it and get it wrong.

For example, I don't think the uri approach of making operator>> space-delimited would cut it for IP addresses, as a common use case might be IP addresses in a comma-separated list. It needs to be more like std::bitset and know about its format and when to stop parsing. However, that implies that operator>> is almost a reimplementation of inet_pton.

But if you want to have a crack at specifying it, go right ahead :)

Cheers,

Chris

[Stack Machine]

Am Samstag, 24. Mai 2014 02:48:43 UTC+2 schrieb chris_kohlhoff:

On Monday, May 5, 2014 12:34:45 AM UTC+10, Stack Machine wrote:

Is there a specific reason why address is not a union of address_v4 and address_v6?

That's effectively what it is, i.e. a discriminated union. Whether it uses a union internally is an implementation detail.

I'm not quite sure if that is the right approach. What if the standard mandated that address be the same size as address_v6? That way address objects can fit into one 128 bit register or 2 64 bit registers.

[Dean Michael Berris]

On Sat, May 24, 2014 at 11:04 AM, chris_kohlhoff
<chris_k...@fastmail.fm> wrote:
>
>
> On Tuesday, May 6, 2014 12:20:58 PM UTC+10, Dean Michael Berris wrote:
>>
>> Thanks for this Chris!
>>
>> I've a few questions, hoping you can clarify:
>>
>> - Have you considered using a string_view instead of the overloads for
>> string, const char*?
>
>
> There are multiple approaches to string handling in the standard library and
> the forthcoming technical specifications. I'm leaving this alone to allow
> the LWG to decide which approach they prefer.
>

Sounds good to me. I'm slightly in favor of string_view, but that may
just be me. :)

>>
>> - Are you flexible on whether to remove the "is_class_{a,b,c}" members
>> on address_v4 and just opt for returning the subnet length?
>
>
> The is_class_*() functions are provided because the equivalent IN_CLASS*
> macros are part of BSD sockets. Particularly with the availability
> constexpr, people shouldn't have a need to reach for those macros any more.
>

Well, that's true only for literal address_v4 instances -- which I'm
positive should be useful, but I worry that having it as member
functions is a little impractical. I would suspect something like
this:

constexpr is_class_A(const address_v4& address);

might suit the case where the address_v4 is actually a literal -- if
it's not a literal, then the computation can still happen at runtime.

> On the other hand, the subnet length is not something that can be reliably
> determined from an address alone. You need to have the subnet length
> explicitly specified or be able to look up the address's subnet in the
> routing table. For this reason I have also removed the netmask() function
> from ip::address_v4 in this revision.
>
> And I agree that this is indeed the job of a separate class like you say:
>
>>
>> - address_v4 looks like an address_range_v4 though if you're hoping to
>> answer the question of what the bitmask is. I would suggest keeping an
>> address_v4 a pure address value type, and flesh out instead an
>> address_range_v4 that gives the answers to questions like: what is the
>> address mask, what is the prefix length, what is the broadcast
>> address, network address, how many addresses are there in this range,
>> etc.
>
>
> Whether that's an address range, cidr_address or whatever, is a discussion
> we should have. However, it's deliberately out-of-scope for this proposal in
> the interests of getting something standardised.
>

Agreed. This comment was made in the context of (and hoping) that some
of the functions relating to network masks and "IP block classes"
would be reconsidered. I see that you've removed the netmask bit which
addresses my original concern.

>>
>> - I see an ostream<< overload but not an ostream>> overload -- is this
>> by design or just an inadvertent oversight?
>
>
> It's a deliberate omission as I think it's difficult to specify operator>>
> correctly for IP addresses. I'd rather not provide it than try to provide it
> and get it wrong.
>
> For example, I don't think the uri approach of making operator>>
> space-delimited would cut it for IP addresses, as a common use case might be
> IP addresses in a comma-separated list. It needs to be more like std::bitset
> and know about its format and when to stop parsing. However, that implies
> that operator>> is almost a reimplementation of inet_pton.
>
> But if you want to have a crack at specifying it, go right ahead :)
>

I'm happy enough to leave this alone for now. I suspect the question
will come up too, and the answer may be as simple as "do what the
other standard types do" in which case looking at operator>> overloads
for std::string is a good precedent for keeping operator>> simple and
predictably consistent (say, whitespace-delimited for some definition
of whitespace).

Thanks Chris!