You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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);
returnstd::move(result).str();
}
intmain() {
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.
}
The text was updated successfully, but these errors were encountered:
@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.
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.
@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?
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 astd::unique_ptr&
, which one should avoid but use a raw pointer (or something likeobserve_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.The text was updated successfully, but these errors were encountered: