Added equality operators between IPAddress types and in_addr types.

[Dimi1010]

Centralized code for comparing IP address equality between IPAddress derived types and in_addr structures.

[tigercosmos]

thanks a lot, much cleaner!

[seladb]

Is there any reason not to include those methods as part of the IPv4Address and IPv6Address classes? 🤔

[Dimi1010]

Wasn't sure if we would want the pure IPAddress.h header to have forward declarations of in_addr and in6_addr structs, or was kept clean for some reason as it mostly included only standard headers. It would be easier to be all in one place if that is not an issue.

[tigercosmos]

@seladb I thought the same thing in the beginning, I guess @Dimi1010 wants to put the two following methods together:

inline bool operator==(const IPv4Address& lhs, const in_addr& rhs) 
inline bool operator==(const in_addr& lhs, const IPv4Address& rhs)

if we put the == method in the class, e.g.

bool IPv4Address::operator==(const in_addr& other) ;

then we still need to declare the following function somewhere else:

bool operator==(const in_addr& lhs, const IPv4Address& rhs)

[seladb]

I think we can put bool IPv4Address::operator==(const in_addr& other) inside the class, and bool operator==(const in_addr& lhs, const IPv4Address& rhs) further down in the file? 🤔

I guess that a forward declaration of in_addr and in6_addr is not an issue, do you think otherwise?

[Dimi1010]

I think we can put bool IPv4Address::operator==(const in_addr& other) inside the class, and bool operator==(const in_addr& lhs, const IPv4Address& rhs) further down in the file? 🤔

Should not be an issue.

I guess that a forward declaration of in_addr and in6_addr is not an issue, do you think otherwise?

Not really, outside of a little global namespace pollution in IPAddress.h by the 2 structs.

It is mostly as I initially just included the entire IPUtils.h header in the IPAddressUtils.h to get the in_addr structs and did not want to include the entire header in IPAddress.h. It was only changed to a forward declaration later, and at that point it was already separate files. ¯\_(ツ)_/¯

If all that is ok, I can have it done when I get some free time.

[seladb]

I have second thoughts on this... 🤔

I don't think we have in_addr and in6_addr anywhere in our API, I'm not sure we want to include it...

[Dimi1010]

I have second thoughts on this... 🤔

I don't think we have in_addr and in6_addr anywhere in our API, I'm not sure we want to include it...

As is, the IPAddressUtils.h can be included separately in the translation units that directly operate with in_addr and in6_addr already and need the comparison operators, so it will not pollute the API unless included.

[seladb]

ok, let's keep it as is. Can you add tests?

[Dimi1010]

Where do the tests of Common++ go?

[tigercosmos]

consider adding tests in Tests/Pcap++Test/Tests/IpMacTests.cpp

[tigercosmos]

Looks good, I cannot find any thing wrong.