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

Olivier Goffart olivier at woboq.com
Thu May 14 09:33:59 CEST 2015

On Thursday 14. May 2015 08:48:36 Thiago Macieira wrote:
> On Thursday 14 May 2015 02:15:54 Marc Mutz wrote:
> > On Wednesday 13 May 2015 23:36:29 Olivier Goffart wrote:
> > > On Thursday 14. May 2015 05:57:54 Thiago Macieira wrote:
> > > > You cannot compare the addresses [of inline methods]
> > > > This is intentional and if you rely on that, your code is flawed by
> > > > design.
> > > 
> > > Why not?
> > > The C++ standards does not forbid it. It defines that it works. I see no
> > > exceptions for inline functions in ยง5.10 (C++14).
> > > 
> > > We rely on this when connecting using function pointers to inline slot
> > > with Qt::UniqueConnection
> > > 
> > > So if the two connect statements are in different library that might
> > > fails...
> > 
> > The standard doesn't talk about DLLs and SOs. Semantics of those
> > constructs is supplied by the platform ABI, not std-C++.
> Right.

Allow me to disagree!

The standard C++ defines all the semantics of the code unless it defines it as 
implementation-defined or undefined behaviour.
The ABI is just an implementation detail and cannot overwrite the C++ 

For example, the C++ standard says that sizeof(char) is 1, and the ABI cannot 
say sizeof(char) is 4.
Likewise, the C++ standard says that function pointers "compare equal if they 
are both null [or] both point to the same function". The ABI cannot overwrite 
that and say "but not for inline functions"

> My point is that we made that choice when we decided to use -fvisibility-
> inlines-hidden.

Ok, so we took the decision to use a compilation flag that is documented to 
break the C++ standard.  But then we probably should document it as well, no?

> Try not to take the addresses of inlines and, if you do, don't compare them.

But this is not documented.
I would not say that someone you compare function pointer to inline function 
is "flawed by design".

> UniqueConnection does not work for functors anyway, so people should get in
> the habit of assuming it doesn't work for anything else.

This is not an argument.  It's like saying "square root does not work with 
negative number so people should get in the habit of assuming it doesn't work 
for anything else."

More information about the Development mailing list