Another draft of IP address proposal

[chris_kohlhoff]

Hi,

Please find attached another updated draft of the three class IP address proposal. The list of all changes is now at the end, but you can also see the changes at its github page:

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

I'd appreciate it if someone is able to eyeball it before it gets submitted this weekend.

Cheers,

Chris

[Stack Machine]

• Your parameter style in the <network> synopsis inconsistent. Sometimes you specify names, sometimes you don't.
• Why is to_string a member function? Shouldn't it be a free function like std::to_string for built-in types? If not, why not provide one that calls the member version - for symmetry?
• The address_vX::broadcast(address_vX, address_vX) overloads look problematic to me, as the mask is represented as an address object. However, since not all addresses are valid host masks, it seems better to me to propose that function in a seperate proposal where we have a type that can represent subnet masks or subnets.
• Why is the function to_ulong named to_ulong? On my platform unsigned long is 64 bits. That doesn't make sense.
  
• Is there no way to create a constexpr address from a string literal? :(
• Why does to_bytes return the bytes in network byte order? What if I want them in host byte order?

[chris_kohlhoff]

Thanks for the comments.

On Saturday, May 24, 2014 8:04:37 PM UTC+10, Stack Machine wrote:

• Your parameter style in the <network> synopsis inconsistent. Sometimes you specify names, sometimes you don't.

Can you please be specific? I cannot spot any parameter names in the <network> synopsis.

• Why is to_string a member function? Shouldn't it be a free function like std::to_string for built-in types? If not, why not provide one that calls the member version - for symmetry?

As I've noted in a couple of other posts: there should be a precedent (and there isn't for you what you propose AFAIK), the current name is based on bitset, and I'm leaving it to the LWG to determine the preferred approach.

• The address_vX::broadcast(address_vX, address_vX) overloads look problematic to me, as the mask is represented as an address object. However, since not all addresses are valid host masks, it seems better to me to propose that function in a seperate proposal where we have a type that can represent subnet masks or subnets.

From a practical point of view I disagree. Netmasks are often represented as dotted decimal addresses, and I am aware of software that uses this notation to determine the broadcast address.

• Why is the function to_ulong named to_ulong? On my platform unsigned long is 64 bits. That doesn't make sense.

Saying "doesn't make sense" is an overstatement. An unsigned long is large enough to hold the value.

Really though, this proposal predates uint32_t and friends, and the name comes from std::bitset. It could probably renamed to to_uint32() and return uint_least32_t. As you still have to check for too-large values, I don't have a strong view either way.

• Is there no way to create a constexpr address from a string literal? :(

No. 

• Why does to_bytes return the bytes in network byte order?

It is the standard representation. 

• What if I want them in host byte order?

If to_ulong (or whatever it ends up being called) doesn't meet your needs, maybe you would like to propose additional hton/ntoh overloads for byte ranges?

Thanks again.

Cheers,

Chris

[Jamie Allsop]

On 24/05/14 12:29, chris_kohlhoff wrote:

Thanks for the comments.

On Saturday, May 24, 2014 8:04:37 PM UTC+10, Stack Machine wrote:

• Your parameter style in the <network> synopsis inconsistent. Sometimes you specify names, sometimes you don't.

Can you please be specific? I cannot spot any parameter names in the <network> synopsis.

I think he means between sections 6.3.1 and 6.3.2 (and 6.3.3, 6.3.4) for example you have parameter names for the relational operators but not others. So not in the synopsis section actually but in 6.3.2, 6.3.3 and 6.3.4. Stylistically what is preferred?

Jamie

[snipped remainder]

[Jamie Allsop]

Looks good to me. One thing I personally would prefer is std::network over std::net for the namespace since that seems to correlate nicely with #include <network> (for example). Apologies for not raising this earlier as I've only noticed this now. I think the slightly more cryptic net is not sufficiently shorter or more readable than network which is short enough and very clear.

Jamie

Cheers,

Chris

--
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.

[Glyn Matthews]

On 24 May 2014 13:57, 'Jamie Allsop' via SG4 - Networking <netwo...@isocpp.org> wrote:

On 24/05/14 01:46, chris_kohlhoff wrote:

Hi,

Please find attached another updated draft of the three class IP address proposal. The list of all changes is now at the end, but you can also see the changes at its github page:

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

I'd appreciate it if someone is able to eyeball it before it gets submitted this weekend.

Looks good to me. One thing I personally would prefer is std::network over std::net for the namespace since that seems to correlate nicely with #include <network> (for example). Apologies for not raising this earlier as I've only noticed this now. I think the slightly more cryptic net is not sufficiently shorter or more readable than network which is short enough and very clear.

The fundamentals TS uses the header <experimental/net> and the namespace name "net".

http://cplusplus.github.io/fundamentals-ts/fundamentals-ts.html#net

FWIW, I agree with Jamie that the name "network" is preferable.

Regards,

Glyn

 

[chris_kohlhoff]

If we're going wordy, for the IP address I'd prefer just "internet". Following the example of the fundamentals TS, the word network could just appear as an inline namespace:

namespace std {

namespace experimental {

inline namespace network_v1 {

namespace internet {

class address;

...

} } } }

(If aiming for less wordy, I'd go "inet" to mirror POSIX naming.)

We also seem headed towards a monolithic <net> (or <network>) header for all things network TS. I'm not sure we'll be thanked... the domain is quite large.

Cheers,

Chris

[chris_kohlhoff]

Ah ok, thanks.

Looks like my favourite precedent, bitset, takes a bet each way in its header synopsis. I'm in good company :)