[Development] Suggested addition to wiki.qt.io/Coding_Conventions

Marc Mutz marc.mutz at kdab.com
Tue May 19 11:47:47 CEST 2015

On Saturday 16 May 2015 22:01:36 Marc Mutz wrote:
> On Wednesday 13 May 2015 09:30:05 Thiago Macieira wrote:
> > The drawbacks only appear in debug builds, so is this worth the
> > uglification?
> Yet another example of things that go wrong when blindly exporting
> classes wholesale:
> http://testresults.qt.io/logs/qt/qtdeclarative/472c6e2acc170082356db371eb3
> 2b518c449d600/windows7x86windows7x86msvc2010release_developer-
> build/708d34c65c2d74994ac0344f9912adbefe88e067/buildlog.txt.gz
> (from https://codereview.qt-project.org/112431).
> Mind you, the Coding Conventions already forbid to inherit from
> template classes. It's just that it wasn't fixed for Qt 5.
> But the root problem isn't inheriting from templates, it's exporting
> the whole subclass.
> Convinced now?

Taking this train of thought one stop further: this is also makes QString BiC:

  class Q_CORE_EXPORT QString
    // ...
    inline QString(QString && other) Q_DECL_NOTHROW : d(other.d)
    { other.d = Data::sharedNull(); }
    inline QString &operator=(QString &&other) Q_DECL_NOTHROW
    { qSwap(d, other.d); return *this; }

By Sergio's problem, an application built in C++11 debug mode should not be 
able to link against a QtCore built in C++98 mode, either (unresolved 
QString(QString &&)). Yet, that is what we wanted to support with the policy 
that all C++11 code needs to be inline-only.

And don't tell me this ain't a problem in practice - it just caused a CI 
failure on the above-mentioned, perfectly valid, patch :)


Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts

More information about the Development mailing list