static const QString, implicit sharing issue

[Christian Ehrlicher]

No, it was just a guess since there are known issues with QStringLiteral in a plugin when the plugin gets unloaded.
Do you get a useful backtrace? I would maybe change it to

static QString defaultPath() { return QStandardPaths::writableLocation(QStandardPaths::AppDataLocation) + QString("/MPR/"); }

To avoid global statics.

[J.Hilk]

@Christian-Ehrlicher well, that fixes the issue as well, and is probably the more reasonable fix, than adding an empty QString to dataPath when I use it.

Lot's of refactoring to do! x)

Thanks.

[aha_1980]

@J.Hilk

And it is the only feasible solution. Having non-POD-types as global variables is undefined behavior, as the constructor of your global static might be run anytime (and you don't know when). Therefore its eays to access the data before it is initialized.

Regards

[J.Hilk]

@aha_1980
well technically, the only non POD-qualifying trait would be QString not being an intrinsic type - which is enough ;-). Never the less your argument still holds true!

[kshegunov]

Actually I'm pretty sure the problem is not so much it being POD or not, but rather that you have dependent initialization.
dataPath depends on defaultPath but C++ does not guarantee you order of initialization of statics. So dataPath might just be initialized with garbage (i.e. before defaultPath is initialized). Additionally, I think QStandardPaths (I may think wrong) is available only after QCoreApplication is up and running.

[kshegunov]

@J-Hilk, could you try something for me btw, just out of curiosity:

static struct  {
    const QString defaultPath = QStandardPaths::writableLocation(QStandardPaths::AppDataLocation) + QString("/MPR/");
    const QString dataPath = defaultPath + QString("Data/");
} strings;

Does that have the same problem?

[J.Hilk]

@kshegunov very true,

It's probably for the best, if I'll wrap this all in a propper class at this point.
I centralized all those path for 2 reasons.

• I had to change 1 path and boy, was that a pain.
• I wanted to reduze the overall memory consumption of the app.

1. Still applies,
2. doesn't matter if it's not static but constructed at runtime.

legacy code - there's always something x)

---

Does that have the same problem?

I'll test it.

[J.Hilk]

@kshegunov said in static const QString, implicit sharing issue:

@J-Hilk, could you try something for me btw, just out of curiosity:

static struct  {
    const QString defaultPath = QStandardPaths::writableLocation(QStandardPaths::AppDataLocation) + QString("/MPR/");
    const QString dataPath = defaultPath + QString("Data/");
} strings;

Does that have the same problem?

It does not! Works fine with the static struct.

[kshegunov]

Indeed, so you have your answer then. One note: this "hack" is going to work only with dynamic linking. If you go to static you're going to run into the same stuff, and not in a good way ... ;) Static init is per-module, so having only one module means at that struct's init QStandardPaths::writableLocation's statics may just be initialized sometime in the future.

[J.Hilk]

@kshegunov I'm learning something new every day :D

However, I'll stick to the proper class implementation and inherit from that simple class where the standardpaths are needed. It's the way, where the least refractoring is needed. I'm kind of on a deadline so close to christmas x)

Thanks all for bringing light to my dark place, where I spend the last couple of days figuring this out, and I'm cutting it close as it is.

[kshegunov]

@J.Hilk said in static const QString, implicit sharing issue:

@kshegunov I'm learning something new every day :D

Don't we all ... :)

However, I'll stick to the proper class implementation and inherit from that simple class where the standardpaths are needed.

Probably the best and most reliable solution.

I'm kind of on a deadline so close to christmas x)

I hear you brother! I have to deliver on the 2nd of January.