[Development] Suggested addition to wiki.qt.io/Coding_Conventions
Marc Mutz
marc.mutz at kdab.com
Thu May 14 02:13:59 CEST 2015
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.
That's the main rationale.
A secondary effect is that the fewer symbols are exported, the less
corresponding administrative data is emitted for them in DLLs and SOs. That
should positively affect startup time, also on more than one platform and also
in release mode.
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