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

Jiergir Ogoerg f35f22fan at gmail.com
Sun Oct 27 21:51:59 CET 2013

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.

Apparently gotta lock/unlock a mutex on each function call, plus under the
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:
> (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>

More information about the Development mailing list