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

[Phil Weinstein]

Thiago, thanks so much for your precise reply.  We will remove 
QObject::tr() from static const QString initializations.

We're not currently using Qt translation.  But, FWIW, if we were to, I 
guess we would initialize static QStrings in the following way (and not 
worry about them being 'const'):

    class MyClass {
        Q_OBJECT
        private:
           static /*const*/ QString _MyToolTipText_;  // can't be const
           static void initStaticData();

         public:
           MyClass::MyClass()  // ctor1
           MyClass::MyClass(int) // ctor2
    };

    /In CPP file:/
    //
    /*const*/ QString MyClass::_MyToolTipText_;

    MyClass::MyClass() { initStaticData(); ... }
    MyClass::MyClass(int) { initStaticData(); ... }

    void MyClass::initStaticData()
    {
        static bool initDone (false);
        if (!initDone)
        {
           initDone = true;
           MyToolTipText = tr ("It's rude to point");
        }
    }

Phil Weinstein, CADSWES, Colorado, USA
---

On 11/4/2015 6:23 PM, Thiago Macieira wrote:
> 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.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20151109/38d396ae/attachment.html>