Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use <boost::math::policies::real> instead of <real> #131

Merged
merged 2 commits into from Jun 26, 2018

Conversation

@kuhlenough
Copy link
Contributor

commented Jun 25, 2018

When compiling for VxWorks 7
Dinkum STL declares an inline real() function in the global namespace that clang can not distinguish from policies::real otherwise.

Use <boost::math::policies::real> instead of <real>
Dinkum STL declares and inline real() function in the global namespace that clang can not distinguish from policies::real otherwise
@NAThompson

This comment has been minimized.

Copy link
Collaborator

commented Jun 25, 2018

The code changes look good to me, and the build failure appears to be a problem on Travis's side.

@jzmaddock

This comment has been minimized.

Copy link
Collaborator

commented Jun 25, 2018

Ah... question: do we want to have to fully qualify everything in the examples remember that code code gets extracted and injected into the docs. My gut says probably not - std::real should be hidden away inside the std namespace and not cause a conflict here?

@kuhlenough

This comment has been minimized.

Copy link
Contributor Author

commented Jun 25, 2018

With Dinkum there's a real() in the C global namespace that's causing the problem, not std::real. I realize not many platforms are using Dinkum anymore, so the fix is specific. If keeping the examples clean is paramount, an alternative is:

#if BOOST_DINKUMWARE_STDLIB >= 650
#define <real> <boost::math::policies::real>
#endif
@jzmaddock

This comment has been minimized.

Copy link
Collaborator

commented Jun 25, 2018

MSVC uses the Dinkum std lib and there are no issues. So it's restricted to VxWorks. It's also not std conforming to do that, as in:

std::complex<double> cd;
// do something
double d = real(cd); // oops

Unless ::real is an alias for std::real ?

Either way my inclination is to just let the examples fail to build on that one platform, and fix up just the tests.

@kuhlenough

This comment has been minimized.

Copy link
Contributor Author

commented Jun 26, 2018

Update. MS doesn't use the <complex.h> where the conflicting ::real() is defined, there <complex> is Dinkum but, not <complex.h> so this is VxWorks only issue, ( and possibly QNX, )
We asked PJ ...
<pjp>
I believe that it is proper, and even required, to define a slew of C names in both the global and std:: namespace. The problem here is that you're asking the compiler to do too much. It has to determine which overload of real should be chosen for discrete_quantile, the one you're defining or the one from the library. That's a different issue.

I don't see a library bug here, but I'm always prepared to be further educated.

P.J. Plauger
</pjp>
I'm not qualified to have opinion, so I updated the pull request to keep the examples clean, but not build them for VxWorks, as @jzmaddock suggests

@jzmaddock jzmaddock merged commit 5cf434e into boostorg:develop Jun 26, 2018

1 of 2 checks passed

continuous-integration/appveyor/pr Waiting for AppVeyor build to complete
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.