-
Notifications
You must be signed in to change notification settings - Fork 420
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
replace much boost usage with C++11 equivalents #104
Conversation
// TODO: Replace with constexpr when we migrate to C++11 or | ||
// boost::math::constants::phi<FCL_REAL>() if boost version is greater | ||
// than 1.50. | ||
const FCL_REAL phi = (1.0 + std::sqrt(5.0)) / 2.0; // golden ratio |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we consider using constexpr
for phi
, a
, and b
as we're migrating to using C++11?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but sqrt is not allowed in a constexpr
(at least not with latest Xcode).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found that none of the math functions in C++11 are not allowed to use with constexpr
(gcc allows it, but it seems not to be allowed in C++14). Okay, we can't use constexpr
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could do it constexpr by precalculation (as I suggested for pi) if you can find a very high-precision calculator.
+1 for merging. |
I'll test this on Windows since CI doesn't. Also, Travis failed. |
Travis is failing probably because of ancient compilers: gcc 4.6 and clang 3.4. I guess the Travis build matrix needs to be updated. We should also set up Windows builds on Appveyor. I'll make the change. I'll wait a bit to give others a chance to respond. |
@@ -111,7 +111,7 @@ class RSS | |||
/// @brief Volume of the RSS | |||
inline FCL_REAL volume() const | |||
{ | |||
return (l[0] * l[1] * 2 * r + 4 * boost::math::constants::pi<FCL_REAL>() * r * r * r); | |||
return (l[0] * l[1] * 2 * r + 4 * M_PI * r * r * r); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two problems with M_PI
:
- it is a macro and hence untyped; needs to have type FCL_REAL
- it is non-standard (it is a Posix feature, not a C++11 one)
Since "pi" is the only boost math constant FCL used, I think the simplest thing would be to define an fcl::kPi or whatever that could be defined in a common header with something like
constexpr FCL_REAL kPi=FCL_REAL(/*lots of digits of pi copied from a reliable source*/);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
M_PI caused compilation failures in Visual Studio 2015.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
M_PI
works with visual studio if you define _USE_MATH_DEFINES
before including cmath
#ifndef _USE_MATH_DEFINES
# define _USE_MATH_DEFINES
#endif
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
M_PI works with visual studio if you define _USE_MATH_DEFINES
Thanks -- I know about that but it's a non-standard hack so I think Mark's fcl::constants::pi
idea is better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds good
This can be addressed by using trusty environment of Travis. |
std::sort(endpoints[2].begin(), endpoints[2].end(), boost::bind(&EndPoint::value, _1) < boost::bind(&EndPoint::value, _2)); | ||
std::sort(endpoints[0].begin(), endpoints[0].end()); | ||
std::sort(endpoints[1].begin(), endpoints[1].end()); | ||
std::sort(endpoints[2].begin(), endpoints[2].end()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That looks a lot nicer in C++11 than in boost!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is actually not a C++11-related change. (Well, sort of, s/boost/std/g didn't work.) The simplification is because of the operator< declaration in the Endpoint class.
This is great, Mark -- it's so nice to see all those boosts disappear! I hope it still works -- the test suite seems kind of short. |
Does anyone object to defining all mathematical constants (pi and phi) in, say, include/fcl/math/constants.h in the fcl::constants namespace as hard-coded double values:
|
I think that's a good idea! |
@@ -1,3 +1,6 @@ | |||
# force C++11 mode | |||
add_definitions(-std=c++11) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This causes zillions of warnings on Windows -- that should only be added for gcc & clang.
The top-level CMakeLists.txt specifies boost components here. Can you remove any of those with this PR? |
|
||
/// @brief Fitting rule to fit a BV node to a set of geometry primitives | ||
boost::shared_ptr<BVFitterBase<BV> > bv_fitter; | ||
std::shared_ptr<BVFitterBase<BV> > bv_fitter; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is a change to the public API, should we bump the major version number?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I know, we might don't need to bump the major version number because FCL is still in 0.y.z.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point, we should at least bump the minor version then
I personally prefer separating big changes into smaller pull requests, but I'll defer to the crowd here. |
@@ -58,7 +58,7 @@ | |||
#include <map> | |||
#include <string> | |||
#include <iostream> | |||
#include <boost/thread.hpp> | |||
#include <thread> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add #include <mutex>
here -- compile failed on Windows. C++11 doesn't promise that mutex will be defined in thread.
With these changes, this PR builds on Windows VS 2015 Win64, with only the same 4 test failures I saw before:
|
I like the constants proposal! I suggest using higher-precision constants that will get rounded down to FCL_REAL, to make sure the last bit is correct. For example:
That is a |
…ode per compiler (MS VS doesn't like -std=c++11). eliminate some boost components in CMakeLists.txt
I have hopefully addressed the main concerns. After this is merged, I'll fix the Travis CI config. |
There's still packaging issues:
|
I guess those can be addressed later too? |
I can fix the pkgconfig / cmake config files, but wouldn't it make more sense to bump the version when you actually release? There's still quite a bit of boost stuff to eliminate. |
Actually, what cmake config files are you talking about? I thought you meant files like fcl-config.cmake, but this is currently not generated by FCL. |
You're right; there is no cmake config file. I just assumed this had one. I like to bump the version number in the master branch (CMakeModules/FCLVersion.cmake) when breaking changes happen. This way people building from source can see a difference by the version number. I consider the package released when a new tag has been created. |
Thanks! |
|
Apparently, MSVC doesn't like |
Mark, can you fix Travis as part of this PR so we can confirm that it passes? I think that just means changing |
Reviewed changes -- looks great! Ready to merge pending build success. |
I think adding the following to
since trusty has a c++11 compiler |
…t system library: test programs link against it
A first step in eliminating Boost usage. Mostly low-hanging fruit.