Avoid M_PI

[bernhardmgruber]

alpaka/rand/RandDefault.hpp uses M_PI which is a non-standard extension. Please replace the constant by e.g. boost::math::constants::pi.

[fwyzard]

Out of curiosity, which C library does not define M_PI ?

[bernhardmgruber]

I primarily encountered it with MSVC 19.30 (VS 2022), where you need to explicitely ask for it with _USE_MATH_DEFINES before including <cmath>. For some reason we did not have that problem in the CI with VS 2019.

[j-stephan]

It sounds less intrusive to define another preprocessor flag rather than add yet another Boost dependency (see #481).

[sbastrakov]

An own variable template for pi is also an option i think. No ugly all caps name as a bonus

[bernhardmgruber]

It sounds less intrusive to define another preprocessor flag rather than add yet another Boost dependency (see #481).

We already have a Boost dependency. There is no way around it. So why reinvent the wheel?
Plus: C++20 has std::numbers::pi<T>.

IMO the preprocessor flag adds more complexity, since it complicates the build system. And I think we have users, that don't use alpaka's CMake, so they would need to specify the flag manually each time.

[j-stephan]

We already have a Boost dependency. There is no way around it. So why reinvent the wheel?

What are we reinventing? _USE_MATH_DEFINES is the official MSVC way: https://docs.microsoft.com/en-us/cpp/c-runtime-library/math-constants?view=msvc-170

Plus: C++20 has std::numbers::pi.

Then we can switch to that once C++20 is available to us.

IMO the preprocessor flag adds more complexity, since it complicates the build system.

It is literally a one-liner in CMake. And we need to change the build system in Boost's case as well since we would need to check for the existence of boost::math and link to it (even more lines!).

And I think we have users, that don't use alpaka's CMake, so they would need to specify the flag manually each time.

Those don't use MSVC anyway AFAIK.

[fwyzard]

And I think we have users, that don't use alpaka's CMake, so they would need to specify the flag manually each time.

Those don't use MSVC anyway AFAIK.

We don't use CMake, and we don't use MSVC, and have been using M_PI since... (checks)... well, technically "since ever" as far as CMSSW is concerned: the first (pre)release from 2005 was already using it.