[Interest] Can QObject::tr() be used in initialization of static const QString data members? [Qt 5.5.1, Windows]

[Thiago Macieira]

On Wednesday 04 November 2015 15:54:41 Phil Weinstein wrote:
> QUESTION: Is there a way to force the initialization of QMetaObject data
> to avoid this CRASH in Qt5?

Even if you could do this, you don't want it.

> Our large Qt 4.8 application makes use of *Object::tr()* to initialize
> static const QString data members. *This is crashing in Qt5* due to
> dereferencing a NULL pointer in a QMetaObject.

Sorry, but you'll have to fix your code.

If you use tr during static initialisation time, no translation was yet loaded 
with QTranslator, so at best you'd get the English version. If that was 
correct, you didn't need QObject::tr. If it wasn't correct, then you must call 
tr() later.

> Our application is quite huge, and it's going to be very difficult to
> have confidence in the completeness changes to myriad uses of
> Object::tr() across all our modules.  This is a NULL pointer
> derefererence, so it's a hard crash, not just an assertion failure. *So
> we really are hoping to find* a "centralized" solution, e.g. an explicit
> global initialization call.

Sorry, your application is faulty. It's doing something unsupported (using 
QObject methods before QCoreApplication) and doing something that was 
pointless anyway (asking for a translation at a point before any translations 
were loaded). 

The interesting thing is your backtrace ends in a function that is accessing 
only static data.... it should have been impossible to crash in it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center