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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development