[Development] Is Qt allowed caching the home dir path?

[Jiergir Ogoerg]

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 <olivier at woboq.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131027/24835742/attachment.html>