[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