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

Enhance XPtr to set and check type info #1212

Open
eddelbuettel opened this issue Apr 2, 2022 · 6 comments
Open

Enhance XPtr to set and check type info #1212

eddelbuettel opened this issue Apr 2, 2022 · 6 comments

Comments

@eddelbuettel
Copy link
Member

The XPtr class wraps somewhat narrowly around R's own external pointers. The class actually has three fields: the pointer, a tag and a protect field. WRE, Section 5.13.1 has an example of setting the tag (of type SEXP, so can be anything) to a string. Searching the CRAN org here at GitHub (with its effective CRAN mirror) shows a few packages using this ... for various purposes, sometimes even second payloads.

Now, because the external pointer is effectively a naked C pointer, it would be useful to also offer some type checking. Following some initial discussion (thanks, @ihnorton) I am currently prototyping use with the tiledb package. But as this is generally useful we should support it here in time (maybe the July release, maybe next January).

Among the obvious missing features are

  • a tag getter in the XPtr class
  • an alternate XPtr creation helper setting pointer and tag
  • and likely more

Following some quick discussion with @Enchufa2 there is also an idea to automate this further via typeid() and std::type_info() (though that may not work for user-defined classes, where I also ran into some potholes on initial probing with C++17-ish features).

In any event, this seems like a fruitful avenue to venture down so opening this ticket to collect more ideas.

@Enchufa2
Copy link
Member

Enchufa2 commented Apr 2, 2022

On second thought, a drawback of automatic type checking is that it wouldn't work with polymorphism. And I use this quite a lot.

@eddelbuettel
Copy link
Member Author

Good catch. Optional extension in derived class as we riffed may be the way to go.

@eddelbuettel
Copy link
Member Author

FWIW that is now in release 0.12.0 of package tiledb -- but we use C++17 there and I haven't checked if what I use there can be used with older compilation standards too.

@github-actions
Copy link

This issue is stale (365 days without activity) and will be closed in 31 days unless new activity is seen. Please feel free to re-open it is still a concern, possibly with additional data.

@eddelbuettel
Copy link
Member Author

Still on the TODO list...

@eddelbuettel
Copy link
Member Author

The tagging idea I had (and use in tiledb does not fully generalise. Package nanoarrow for example uses the SEXP field to store another external pointer (!!) as Arrow data structures prefer to come in pair: 'data' (usually called 'array') along with 'schema'.

So maybe a better idea is to use an additional attribute?

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

2 participants