[Development] Suggested addition to wiki.qt.io/Coding_Conventions
thiago.macieira at intel.com
Thu May 14 12:08:30 CEST 2015
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++
> 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,
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
More information about the Development