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

Missing default constructor for zfparray view #58

Closed
harshithamenon opened this issue Apr 24, 2019 · 1 comment
Closed

Missing default constructor for zfparray view #58

harshithamenon opened this issue Apr 24, 2019 · 1 comment

Comments

@harshithamenon
Copy link

In certain cases having a default constructor for the zfparray view class is helpful. For example, when the view is part of another object.

@lindstro
Copy link
Member

lindstro commented Nov 8, 2019

A view should be thought of as a reference that generalizes single-element access to contiguous subarray access. Built-in references in C++ cannot be default initialized or reseated, nor is such functionality available for zfp's array::reference or STL's container references (though std::reference_wrapper supports this behavior). As far as I know, C++'s mdspan views of multidimensional arrays do not provide this capability either.

I'm not trying to make life more difficult for zfp users, but I wonder if this capability truly is needed. I'm also unsure what the API ought to look like. For instance, does assigning one view to another (which I believe would be needed to reseat the view) have value or reference semantics? Consider the analogous code snippet for references:

  type& a = b;
  a = c;

The assignment a = c actually copies the value of c to b (through the reference a) rather than reseat a to reference c. One way around this would be to provide a new function, e.g., a.rebind(c).

It would be beneficial to see examples where this functionality is needed as well as examples of APIs that provide such functionality.

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

No branches or pull requests

3 participants