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

Have jlcxx::Array be a bit more like a Container #62

Open
rgcv opened this issue Jul 1, 2020 · 0 comments
Open

Have jlcxx::Array be a bit more like a Container #62

rgcv opened this issue Jul 1, 2020 · 0 comments

Comments

@rgcv
Copy link
Contributor

rgcv commented Jul 1, 2020

Specifically, as described in cppreference. A minor change such as typedefing the container's value_type already allows the usage of std::back_inserter.

As an example of such usage, here's a use case of mine - calling a function requiring an OutputIterator as argument:

mod.method("oifunc", [](jlcxx::ArrayRef<int> is) {
  jlcxx::Array<int> res;
  oifunc(is.begin(), is.end(), std::back_inserter(res));
  return res;
});

Otherwise, I'd probably need to do something like the following (if I still want to return a julia array, i.e. jlcxx::Array):

mod.method("oifunc", [](jlcxx::ArrayRef<int> is) {
  std::vector<int> res;
  jlcxx::Array<int> jlres;

  oifunc(is.begin(), is.end(), std::back_inserter(res));

  auto it = res.begin();
  while (it != res.end()) jlres.push_back(*it++);
  return jlres;
});

EDIT: Assuming the following definition:

template<typename InputIterator, typename OutputIterator>
oifunc(InputIterator begin, InputIterator end, OutputIterator out);

I'm not sure if making types like jlcxx::Array closer to STL-like spec is in the horizon, seeing one could just leverage the already in-place STL capabilities and just using jlcxx::apply_stl<T>(). Nonetheless, it would make usage more practical.

Addendum: Albeit slightly unrelated, I think this issue pairs nicely with #58.

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

1 participant