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

[Thiago Macieira]

On Thursday 14 May 2015 09:33:59 Olivier Goffart wrote:
> 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++
> standards.
> 
> 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"

Correct. According to the standard, that is the case.

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

Why? Where does it affect our users?

We only do it inside the signal-slot system. All signals are, by construction, 
non-inline and we've gone through great pains to ensure that their addresses 
can be compared.

The slots are a different matter. First of all, we don't often use 
UniqueConnection in our code and, when we do, we don't expect users to go and 
disconnect or reconnect what we've connected. So I don't see how it affects the 
users and therefore, there's nothing to be documented.

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

No, it's just good programming practice. If you take the address of a 
function, you force it to exist out-of-line (unless the compiler actually does 
constant propagation and inlines it through the pointer call)..

We don't have to do everything the standard tells us to do. The standard says 
exceptions are good, we disagree.

Another ABI issue is that we need to force the virtual tables to be anchored 
in a single library, which means all polymorphic classes must have at least 
one non-inline virtual member. The standard doesn't require that, but it's a 
good idea to so it.

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

Well, they should if they don't control the input range. If you wrote code 
that depended on the result of sqrt() but didn't ensure that the input was 
non-negative, you'd eventually run into problems.

Given that people use lambdas and functors (like std::bind, std::function, 
etc.) quite often, they need to learn that UniqueConnection won't work for 
them in all cases. Better simply not rely on the feature.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center