Thanks, that looks like a nice and elegant solution. But looking at its source code [1] and since this was a micro-optimization to begin with, I guess it's not worth bothering caching the home dir path.
[1] Apparently gotta lock/unlock a mutex on each function call, plus under the hood Q_GLOBAL_STATIC introduces a wrapper class around the QString with thread safety solutions which don't matter for this simple case. As to me personally I didn't fully get how it works since it's wrapped in further Qt macros and is slightly weird, from the docs: "But due to the non-atomic nature of construction, this function may return false for a short time after the construction has completed." On Sun, Oct 27, 2013 at 6:13 PM, Olivier Goffart <[email protected]> wrote: > On Sunday 27 October 2013 04:53:41 Jiergir Ogoerg wrote: > > It looks like only the home and temp dir paths are worth caching, their > > window$ implementation is ~ 30-40 lines of code > > if counting QDir's subcalls to QFileSystemEngine. > > > > For these two QDir functions to stay one liners and lock-less (while > thread > > safe), I'm caching the paths in QDirPrivate > > (QTSRC/qtbase/src/corelib/io/qdir_p.h and > > QTSRC/qtbase/src/corelib/io/qdir.cpp), > > Don't use global static QStrings. (they have a constructor that is run at > load > time of the library, we don't allow that within Qt) > > Use the Q_GLOBAL_STATIC macro. > Something like this: > > > Q_GLOBAL_STATIC_WITH_ARGS(QString, homePath, > (QFileSystemEngine::homePath())); > QString QDir::homePath() > { > return homePath(); > } > > -- > Olivier > > Woboq - Qt services and support - http://woboq.com - http://code.woboq.org >
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
