Re: TrackerRequestDriver feedback

Hi Peter,

Just checked your rev 140:
[cut]
and I thought that we actually need and would need this thing quite often. For example Protocols::Generics::VendorCode is just that - 4 byte QByteArray. We could make a template out of it - something like FixedByteArray taking an int as a template argument. They we could define VendorCode as a typedef for FixedByteArray <4>. Similarly we could define RawPeerId as a typedef for FixedByteArray <20>

Yes, this should work. I’m now thinking about two things, though:

  • We can’t guarantee that to the FixedByteArray constructor one wouldn’t pass array with different number of bytes (or to some member function, if any), so we should think of some validation method - maybe “Null object” pattern will be suitable.
  • We were once or twice talking about the HashDigest class which we’ll use to store various hashes, so for example for the info hash value we could use a (new) Sha1Digest class. This class will also guarantee hash length validation.

And then we can add preconditions to the TrackerRequestWriter (and to other classes as well) that these input (fixed length arrays) objects must be valid - assertions in the code will check that.

Petr

Would you like to post a relpy?


This post is a reply to:
Re: TrackerRequestDriver feedback
Hi Petr, Just checked your rev 140: \todo Add assertions/validations for hash info and peer ID (these have to be correctly set and (more...)

Follow-ups:
Re: TrackerRequestDriver feedback
Hi Petr, - We can’t guarantee that to the FixedByteArray constructor one wouldn’t pass array with different number of bytes (or to some member function, if any), so we should think (more...)