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

[util] move bounds to geometry::util #1254

Merged
merged 1 commit into from
Mar 26, 2024

Conversation

barendgehrels
Copy link
Collaborator

This is a follow up on numeric_cast - now for bounds - which is different and simpler because it was already a structure.
It also adds unit tests for it.
So bounds for Boost.Rational was stil necessary.

It also adds CMakeLists.txt for the folders which tests which were affected

{
return boost::rational_cast<Target>(source);
}
};
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was placed here in last commit, but it is more consistent with other approach if it is all in rational.hpp (it was there before as well)

@barendgehrels barendgehrels self-assigned this Mar 3, 2024
@awulkiew
Copy link
Member

awulkiew commented Mar 3, 2024

Thanks, I think util is a better place for this. We could also consider math.

With that said. What do you think about removing it after rewriting or deprecating algorithms using bounds? It's because the library supports any coordinate type even big numerical types with dynamic size that have no bounds, e.g. Boost.Mutiprecision. AFAIR in the past we made a decision to not use assign_inverse in the library. This utliity was left for backward compatibility and if it was used I'd consider this as a bug. What do you think?

Btw, C++14 has this: https://en.cppreference.com/w/cpp/language/attributes/deprecated

@barendgehrels
Copy link
Collaborator Author

Thanks, I think util is a better place for this. We could also consider math.

With that said. What do you think about removing it after rewriting or deprecating algorithms using bounds? It's because the library supports any coordinate type even big numerical types with dynamic size that have no bounds, e.g. Boost.Mutiprecision. AFAIR in the past we made a decision to not use assign_inverse in the library. This utliity was left for backward compatibility and if it was used I'd consider this as a bug. What do you think?

Btw, C++14 has this: https://en.cppreference.com/w/cpp/language/attributes/deprecated

Didn't answer this yet. But yes, it makes sense. We use it in some places, but not often. And yes, assign_inverse we can deprecate, I forgot it, but I guess it was mainly for spherical/geographic

@barendgehrels
Copy link
Collaborator Author

There was one comment but I don't think it will change the PR.
Can it be approved? @awulkiew @vissarion

@awulkiew
Copy link
Member

lgtm thanks.

Copy link
Member

@vissarion vissarion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, thanks!

@barendgehrels barendgehrels merged commit d9eface into boostorg:develop Mar 26, 2024
23 checks passed
@barendgehrels barendgehrels deleted the fix/bounds branch March 26, 2024 17:18
@vissarion vissarion added this to the 1.85 milestone Apr 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants