Since Qt 4.7, the QString class has gained a constructor. It used to have QString(const char *), QString(const QChar *, int) and a bunch of others. Now it has QString(const QChar *) as well. This constructor works with 0-terminated QChar sequences, like char * does. A useful addition, except that it makes certain other code constructions newly ambiguous.

Consider code that uses 0 as a pointer; this is now ambiguous because that might be a const char * or a const QChar *. There's code in KDE where 0 is used in places for QStrings, and this used to work, like class A { public: A() : a(0) {} ; QString a; } ; You don't always see it that obviously; for instance, there's arrays of structs with a terminating null struct -- a real C-ism. It becomes ambiguous with a QString member: struct { int, int, QString } foo[] = { ..., { 0,0,0 } } . For some reason we hit these more clearly in Solaris (OpenIndiana, that is), and we've started to fix them. The simple fix is to use QString() to mean an empty string (QString::null? damn I'm oldschool).

One more reason to look forward to nullptr (didn't mpyne or MarcM mention that recently?).