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

[Olivier Goffart]

On Friday 15. May 2015 07:59:19 Marc Mutz wrote:
> On Thursday 14 May 2015 02:04:44 Thiago Macieira wrote:
> > On Thursday 14 May 2015 02:13:59 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?
> > > 
> > > No, the drawbacks are *due to* MSVC debug builds. They *appear* in
> > > release builds and all platforms, too. Exporting the whole class
> > > restricts what kind
> > > 
> > > of changes we can make in a BC way. See e.g. QStringRef:
> > >     // ### Qt 6: make this constructor constexpr, after the destructor
> > >     is
> > > 
> > > made trivial
> > > 
> > >     inline QStringRef():m_string(0), m_position(0), m_size(0){}
> > >     // ### Qt 6: remove this copy constructor, the implicit one is fine
> > >     inline QStringRef(const QStringRef &other)
> > >     
> > >         :m_string(other.m_string), m_position(other.m_position),
> > > 
> > > m_size(other.m_size)
> > > 
> > >         {}
> > >     
> > >     // ### Qt 6: remove this destructor, the implicit one is fine
> > >     inline ~QStringRef(){}
> > > 
> > > I remember many more situations where this prevented useful changes,
> > > though I'd have to dig deeper to provide details.
> > 
> > None of the three in your example are due to DLL exporting, outside of
> > MSVC
> > debug builds.
> > 
> > The restriction on removing them right now is because doing so would make
> > the class trivially copyable or even trivial, which in turn means it's
> > passed differently (in registers) when passed by value. That has nothing
> > to do with DLLs and we cannot make trivial what wasn't trivial or
> > vice-versa.
> 
> Interesting. I didn't know that. Please document it on
> https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++
> 
> I guess that means we should revert
> ab8366b5923ec0feb730df98040885669f7bbe38, too?

Yes, it should be reverted. I did not think about that.


> Then again, C++98 doesn't have the concept of trivial types. And QStringRef,
> after the proposed changes for Qt 6, still isn't a C++98 POD. Does that
> mean that C++11/C++98 builds become binary incompatible?

No, because the ABI is not specified by the C++ standard and the itanium C++ 
ABI already specified the concept of types with "non-trivial copy constructor 
or destructor" from the beginning.

C++14, C++11 and C++98 builds should be binary compatible. (Unless of course 
some symbols are added only conditionally with #ifdefs)

-- 
Olivier 

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org