[Bro-Commits] [git/bro] topic/v6-addr: Interface draft for new IP address wrapper class. (0868317)

Development
1

Interface draft for new IP address wrapper class.

This looks like a good start; a few comments below.

+public:
+ /// Address family.
+ enum { IPv4, IPv6 } Family;

Why is that (and ByteOrder) a public member? Intuitively, I would
imagine that the constructor sets this value once and then clients only
use the family() const member function to inspect it.

+ /// Byte order.
+ enum { Host, Network } ByteOrder;

Why is it necessary to discern between the two? I might oversee a use
case that requires this differentiation, but in my naive mental model,
only a single internal representation is necessary (with a constructor
argument specifying the order when creating an instance from raw bytes).

+/// Comparision operator for IP addresss.
+extern bool operator==(const IPAddr& addr1, const IPAddr& addr2) const;
+
+/// Comparision operator IP addresses. This defines a well-defined order for
+/// IP addresses. However, the order does not necessarily correspond to their
+/// numerical values.
+extern bool operator<(const IPAddr& addr1, const IPAddr& addr2) const;

These could be members, too. Then you could directory access the in6
member.

    Matthias

2

> + enum { IPv4, IPv6 } Family;
> + enum { Host, Network } ByteOrder;

Oops, that are typos. That's supposed to look like this instead:

     enum Family { IPv4, IPv6 };
     enum ByteOrder { Host, Network };

Does that make more sense? :slight_smile:

In other words, we don't need to store these at all.

These could be members, too. Then you could directory access the in6
member.

I have this old rule of thumb in my head to define binary operators
outside of classes. What was the use case where that's needed?

Robin

3

Oops, that are typos. That's supposed to look like this instead:

     enum Family \{ IPv4, IPv6 \};
     enum ByteOrder \{ Host, Network \};

Does that make more sense? :slight_smile:

Yes :-).

I have this old rule of thumb in my head to define binary operators
outside of classes. What was the use case where that's needed?

I think you're actually right: binary operators outside of classes
improve implicit type conversion. Say you implement for some reason
operator/ for IP addresses and have an instance ip of your class, then
the expression

    192.168.0.1 / ip

only works operator/ is implemented as non-member function (in the same
namespace as the IP address class). Or put differently, the member
implementation of a binary operator forces the LHS of an expression to
of that class type, which limits the operator symmetry:

    addr("192.168.0.1) / 192.168.0.1

will work, but

    192.168.0.1 / addr("192.168.0.1)

will not.

    Matthias

4

Ah, right. Thansk!

Robin