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

Corrections when using custom vector types #135

Merged
merged 1 commit into from
Mar 3, 2025

Conversation

romainaugier
Copy link
Contributor

I tried to use tinybvh with custom vector types today and found a few compiler errors when building, so I made a few corrections to make it more usable (most of it was to remove the call to .cell member, make a function for halfArea calculation, and added a const [] operator for const references). Hope it helps!

@jbikker
Copy link
Owner

jbikker commented Mar 3, 2025

That is nice, I didn't know the const and non-const [] operator could co-exist; I see now all it takes is making the method itself const as well. :) For the half-area thing: I suppose this could simply be called 'halfArea' for both double and single-precision; the right version would be picked based on the argument type right? This would be more consistent with the other 'tinybvh_' functions, which do not have the 'f' or 'd' appended.

@jbikker
Copy link
Owner

jbikker commented Mar 3, 2025

Merging the PR, will make the minor changes to the function names separately. Thanks for the contribution!

@jbikker jbikker merged commit 11d6df0 into jbikker:main Mar 3, 2025
6 checks passed
@romainaugier
Copy link
Contributor Author

That is nice, I didn't know the const and non-const [] operator could co-exist; I see now all it takes is making the method itself const as well. :) For the half-area thing: I suppose this could simply be called 'halfArea' for both double and single-precision; the right version would be picked based on the argument type right? This would be more consistent with the other 'tinybvh_' functions, which do not have the 'f' or 'd' appended.

Oh it's my C habits to name the functions based on the datatype, but of course with overloading you can have the same name for both functions and the compiler will pick the right one depending on the arguments and return type! So for consistency with the naming convention it would be better yes.
And regarding the const [] operator, it is very useful to have both (the compiler will resolve which one to call based on either if the return type is a const reference or if the object itself is const, and it's useful for optimizations too)!

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.

2 participants