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 <jfons...@vmware.com>
wrote:
On 18/03/16 04:00, Ilia Mirkin wrote:
On Mar 17, 2016 8:27 PM, "Matt Turner" <matts...@gmail.com
<mailto:matts...@gmail.com>> wrote:
>
> On Thu, Mar 17, 2016 at 5:17 PM, Pierre Moreau
<pierre.mor...@free.fr
<mailto:pierre.mor...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
