Hi Peter,

Any idea how to solve:
[snip]
It appears numerous times and the cause is that Gnutella::Packets::PacketBase and BitTorrent::Packets::PacketBase implement writePayload() and define a new pure virtual function void writePayload (BinaryWriter &), which thir derived classes implement. Maybe to get rid of the warnings we should reimplement both and have one simply call its base class implementation (which is sub-optimal and practically unnecessary).

I think that putting using Packet::writePayload; to these classes (which are derived from e.g. BitTorrent::Packets::Packet) would solve the “problem” - I’m just thinking, isn’t now impossible to call e.g. BitField::writePayload(); (the function from the Packet class) from the derived classes? Because if you create a new function of the same name, but with different signature in the base class and you implement only one of them in the derived class, the second one would be hidden by the first one and thus cannot be called. More details are here. I didn’t study these classes deeply, so correct me if I’m wrong.

Should we not write Gnutella::?

Yes, I think that it’s superfluous in this case.

I’ve also been thinking about the #includes in Import.h/cpp. If we include from a sub-package, then which one should we use:

#include "SubPackage/Module.h" // relative path to this file
#include "Package/SubPackage/Module.h // relative path to project's root

I’d personally stick to the relative path to a file if including from a sub-package. But this is maybe more subjective than objective issue, because if we include from a non-sub-package we have to specify a full path to project’s root.

Regards,

Petr