[Mesa-dev] [PATCH] nv50/ra: `isinf()` is in namespace `std` since C++11

[Jose Fonseca]

On 19/03/16 22:30, Jose Fonseca wrote:
> On 19/03/16 22:25, Ilia Mirkin wrote:
>> On Sat, Mar 19, 2016 at 6:23 PM, Jose Fonseca <jfonseca at vmware.com>
>> wrote:
>>> On 18/03/16 04:00, Ilia Mirkin wrote:
>>>>
>>>>
>>>> On Mar 17, 2016 8:27 PM, "Matt Turner" <mattst88 at gmail.com
>>>> <mailto:mattst88 at gmail.com>> wrote:
>>>>   >
>>>>   > On Thu, Mar 17, 2016 at 5:17 PM, Pierre Moreau
>>>> <pierre.morrow at free.fr
>>>> <mailto:pierre.morrow at free.fr>> wrote:
>>>>   > > This fixes a compile error while building Nouveau with C++11
>>>> enabled (and
>>>>   > > glibc >= 2.23). This happens if SWR is enabled, as it forces
>>>> C++11.
>>>>   >
>>>>   > That seems bad, right?
>>>>   >
>>>>   > Enabling OpenSWR should affect how any other drivers are built. Why
>>>>   > does this happen?
>>>>
>>>> Yeah, the fix here is to fix the build not to add random unrelated
>>>> options from one driver when building another.
>>>
>>>
>>> Although I agree in principle, that drivers should not interfere with
>>> others
>>> build,  C++14 will soon be the default [1].
>>>
>>> So, in this particular case, it seems a missed opportunity not to try
>>> to fix
>>> this generically.
>>>
>>>
>>> What about adding to include/c99_math.h something like
>>>
>>> #if __cplusplus >= 201103L
>>>     using std::isinf;
>>> #endif
>>
>> Why is isinf() becoming unavailable by the way? I don't think anyone's
>> given a clear answer on that. At least I haven't heard one.
>
> It's unavoidable.
>
> On C99 isinf is a macro.
>
> On C++11 isinf is an function inside std namespace.
>
> You can't have a macro inside a C++ namespace -- macros have no namespaces.
>
> So, even if you `#include <math.h>` instead of `#include <cmath>`, the
> math.h must not `#define isinf` so that C-prepposeccor doesn't expan
> `std::isinf` to invalid code.

If you ask me, the moral here is that C runtime library should be 
defined with inline functions instead of macros, at least for 
function-like things.  Macros are bad because they can clash with 
application source code, and cause this sort of obstacles to C/C++ 
unification.

Jose