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

Marc Mutz marc.mutz at kdab.com
Thu May 21 14:54:24 CEST 2015


On Wednesday 20 May 2015 20:23:01 Thiago Macieira wrote:
> On Tuesday 19 May 2015 11:47:47 Marc Mutz wrote:
> > 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
> 
> How?

Compile a QtCore debug version with an MSVC version that doesn't support 
rvalue refs, try to link against an application compiled with an MSVC version 
that does?

> > 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.
> 
> The only compiler with that limitation is MSVC, for which the problem does
> not  apply.

What about the above scenario?

> > 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 :)
> 
> It's not what you described. The problem lies elsewhere.

It's not what I described _in this mail_. The CI failure is caused by a 
similar incompatibility d/t QT_STRICT_ITERATORS, cf. my mail before, yes.

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



More information about the Development mailing list