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

Thiago Macieira thiago.macieira at intel.com
Thu May 14 02:04:44 CEST 2015


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.

> 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.

That has negligible effect. My QtCore has 5914 symbols in the dynamic symbol 
table, of which 5603 are exports from QtCore (311 are imports from other 
libs). But access to those symbols is done via a hashing table, which 
according to eu-readelf:

 Average number of tests:   successful lookup: 1,727257
                          unsuccessful lookup: 1,442791

If you look at the far smaller QtDBus library (437 exports):

 Average number of tests:   successful lookup: 1,837587
                          unsuccessful lookup: 1,654511

Whereas the much larger QtWidgets (9277 exports):

 Average number of tests:   successful lookup: 1,705600
                          unsuccessful lookup: 1,422585

and QtGui (7047):

 Average number of tests:   successful lookup: 1,975401
                          unsuccessful lookup: 1,963650

So in effect, the quality of the hashing function affects lookup a lot more than 
the number of symbols.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Development mailing list