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

[Marc Mutz]

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