Hi Petr,

You are right about BInt! Qt uses qint64 in their QIODevice and derived classes, so I we can use it too.

Another question is whether we should use the 64 bit int in our Transport interface for example? I don’t think we would ever need to write anything close to 4G at once over a Transport - it simply cannot be buffered and makes no sense for networks.

About your second point, I agree that it would be best to abstract the difference in the interface of Torrent. Having two variants for the binary format is all a matter of encoding/parsing. So the torrent would essentially just store a list of FileInfos and this list should have at least one element.

The checksum better be stored in a QByteArray because QString is 32 bit UNICODE. And I think path could be a simple QString containing the complete path name. This would be easier to use than the list of strings and the user would probably have concatenated the list elements anyway.

Btw. since all strings in a bencoded torrent are UTF-8 encoded, and BString stores a QByteArray, then we should create the QStrings using fromUtf8(). Or maybe we should modify BString to store a QString and modify BDecoder to do the conversion?

Let us drop the directoryName. In the multi-file case we could simply append the directoryName to the path while parsing. This would save the user of the class an if or two ;-)

FileInfoList fileInfoList() const; could just return a copy of the list we are storing internally. I’m pretty sure (have to check that though) that they use implicit sharing in QList, so returning the list by value should be inexpensive. No need for iterators in that case.

Regards,

Peter