[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