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 { public: // ... #ifdef Q_COMPILER_RVALUE_REFS 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; } #endif 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 :) Thanks, Marc -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development