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

Differences in API for Views and MultiViews #1571

Open
rcarson3 opened this issue Nov 29, 2023 · 0 comments
Open

Differences in API for Views and MultiViews #1571

rcarson3 opened this issue Nov 29, 2023 · 0 comments
Labels
API/usability reviewed Mark with this label when issue has been discussed by team

Comments

@rcarson3
Copy link
Member

For an internal library I'm working to modernize, we've been transitioning over to either RAJA::View or RAJA::MultiView based on a compile time flag that our application codes would supply.

I've found this works relatively well as long as I'm only using the View::operator(...) function. Unfortunately, I do occasionally need to access the actual raw data from time to time as some of the older portions of the code still expect those. For the RAJA::View, this would be done using the get_data() but for the RAJA::MultiView type it appears that this function does not exist, and I would access the member data function directly. I was wondering if it might be possible to unify the behavior of these types so they have the same API for similar actions?

Also, I do realize that for the this raw pointer use case I'll still have to deal with the one fact one returns just a pointer and the other returns a pointer of pointers, but that's something I can work on internally within my library once I have a consistent API. I could probably have a free function deal with the differences before me in meantime though, but I just thought it was odd that the APIs between those two View types wasn't consistent for simple operations like the above.

@rhornung67 rhornung67 added the reviewed Mark with this label when issue has been discussed by team label Mar 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API/usability reviewed Mark with this label when issue has been discussed by team
Projects
None yet
Development

No branches or pull requests

2 participants