Hi Peter,

and what about:


switch()
{
[snip]


Yes, that sounds reasonably!

However, I’ll try to compile and run `./tester` on our student servers that our faculty provides. There are various OS/compilers, so this way we could see whether there are currently more poblems. There are:

CentOS 64bit Linux - GCC (3.3, 3.4, 4.0, 4.1, 4.2), Intel C/C++ Compiler/Debugger 10.0
FreeBSD 6.2 - GCC (3.4)
Solaris 7 - GCC (3.3), Sun C/C++

So I’ve tried that - there is everything but Qt 4 :( on our servers. Only Qt 3 is present at the moment, so I can’t test it…

Btw, I’ve been thinking whether it will be a good idea to create a simple wrapper around PeerInfo (Uri). What I mean are setters and getters to keep the interface abstraction on the same level. If one wants to add host/port, there is currently no problem:


peerInfo.setHost ("127.0.0.1");
peerInfo.setPort ("6881");


But if one wants to add an ID, he must type:

peerInfo.appendQueryItem (PeerIdQueryItemKeyName, peerId);

which seems a little bit different kind of abstraction (URI like) to me. And if we have a wrapper, there won’t be a need for a user to call peerInfo.setScheme (PeerSchemeName); in PeerInfo creation - this will be done internally in the wrapper.

So I suggest to create an adapter over Uri with setters (and ctor) like setHost();, setPort(); and setPeerId(); and we’ll be able to get the Uri object by calling something like toUri();.

What do you think?

Have a nice day,

Petr