Hi Peter,

I was thinking that we could also provide a named ctor fromUri() to complement the toUri() function.

Sure - good idea. I’ll add it.

Regarding the static initialization dependency, does it still cause trouble if you use QByteArray instead of char *? I think it should not make any difference.

Actually, it does. The initialization order/rules of (non-local) static objects are:

• 1st: All static objects are initialized to zero.
• 2nd: Static objects of intrinsic/primitive types initialized with constant expressions are initialized.
• Static objects of namespace scope defined in the same translation unit are initialized in the order that their definitions appear in the translation unit.

So if one use QByteArray instead of char *, there may be a problem.

The perfect case is when we use static const integral literals, which the compiler can substitute already at compile time - then we have no dependency problems.

Yes, I agree - I’ve already rewritten some static constants types and I’ll take a look on the rest (if any).

I’m not hundred pro sure about this, but from what I recently read, I think that using static const members from within the same class will always work. I guess that is so because before e.g. the ctor gets called the module where the ctor is located must be loaded and one of the first things that will happen upon loading the module is that the static members are be initialized.

No, I think it won’t always work (see my first comment). I’ve tested it in the PeerInfo class - it’s ctor is first called in the TrackerRequestSessionTest.cpp:197 (that’s compiler dependant) and it’s data were not initialized at that moment (recieved segfault).

So, I’d suggest to try creating only intrinsic/primitive (where it’s possible) static constants (in classes/namespaces, excluded tests). Where it won’t be possible (and can make problems), we can still use some more tricky solution like Schwarz counters, but lets first try to use the former solution.

Here is one test that would fail:
[snip]
the internally stored query component of the uri will have become id=peerId1Bytes&id=peerId2Bytes. Calling uri.setQuery(””) before appendQueryItem() would clear the old data. And if we want the strong guarantee of exception safety for setPeerId() we’d better do the job on a temp uri first.

Yes, you’re right! Thanks, I’ll (still and all) add tests to the PeerInfo module.

Regards,

Petr