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

non owning from owning proxy/proxy_view/borrowing proxy? #209

Closed
Shuenhoy opened this issue Nov 29, 2024 · 3 comments
Closed

non owning from owning proxy/proxy_view/borrowing proxy? #209

Shuenhoy opened this issue Nov 29, 2024 · 3 comments
Labels
enhancement New feature or request p1

Comments

@Shuenhoy
Copy link

Shuenhoy commented Nov 29, 2024

I see similar topic has been discussed in #65, but that issue seems to be mostly about the performance, while I want to talk about the usage here.

While proxy already has non owning proxy when a proxy holds raw pointer, there is another situation: the consumer just wants to borrow the proxy, and does not care it is originally owning or non-owning, whether it holds a smart pointer or raw pointer (especially when the facade is move only).

It is only possible to use a proxy& for borrowing now. But, 1) it feels something like a std::unique_ptr& , which one should avoid but use a raw pointer (or something like observe_ptr, though it is abandon), 2) the semantics are not clear enough and if the proxy can not be const, it may be moved by accident.

std::string PrintDrawableToString(pro::proxy<Drawable>& p) {
  std::stringstream result;
  result << "entity = ";
  p->Draw(result);
  result << ", area = " << p->Area();
  auto b = std::move(p);
  return std::move(result).str();
}

int main() {
  pro::proxy<Drawable> p = pro::make_proxy<Drawable, Rectangle>(3, 5);
  std::string str = PrintDrawableToString(p);
  std::cout << str << "\n";  // Prints: "entity = {Rectangle: width = 3, height = 5}, area = 15"
  std::string str2 = PrintDrawableToString(p); // Assertion `p.has_value()' failed.
}
@mingxwa mingxwa added enhancement New feature or request p1 labels Dec 2, 2024
@mingxwa
Copy link
Collaborator

mingxwa commented Dec 2, 2024

@Shuenhoy Thank you for the feedback! I think this is an interesting area worth exploring. While we will investigate further, please let us know if you have any further thoughts in API design or potential implementation.

@Shuenhoy
Copy link
Author

Shuenhoy commented Dec 3, 2024

I am attending a graphics conference this week, so I will just briefly describe what I am thinking about. I can discuss more next week if necessary.

I propose proxy_view. It can be viewed as something similar to proxy that only accepts the raw pointers. But it can be constructed from the other smart pointer types, in that case it will take the raw pointer of the smart pointer (e.g. unqiue_ptr::get()). It may also be constrcuted from the normal proxy, also by taking the raw pointer of the underlying pointer type, so we can "borrow" a proxy. There should be proxy_view<Facade> borrowing a proxy<Facade> and proxy_view<const Facade> borrowing a const proxy<Facade>, just like std::view.

@mingxwa
Copy link
Collaborator

mingxwa commented Dec 14, 2024

@Shuenhoy Thank you for the insights! I agree having a proxy that only accepts raw pointers should be useful. However, implicitly taking a raw pointer from a smart pointer is beyond the current design scope of proxy. As long as the caller side can effectively call .get() from a smart pointer, I don't think the motivation is enough to move this responsibility to the scope of proxy.

I have filed PR #218 to implement a prototype of proxy_view as an alias of proxy. Could you help review and let me know if it meets your expectations?

@mingxwa mingxwa closed this as completed Dec 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request p1
Projects
None yet
Development

No branches or pull requests

2 participants