Creating a pro::proxy_view from a pro::weak_proxy

[jeanga]

Hi!

My question is about the process of proxy_view creation from a weak_proxy.

My (pseudo) code:

struct Identity : pro::facade_builder
    /// Conventions go here
    ::template add_skill<pro::skills::as_weak>
    ::template add_skill<pro::skills::as_view> 
    ::build
{
};

pro::proxy_view<Identity> as_view(const pro::weak_proxy<Identity>& type)
{
    if (type)
        return type.lock();
    return {};
}

My understanding is that this code will create a temporary pro::proxy just to create the pro::proxy_view before being deleted. Is that correct ?

Has the weak_proxy enough information to check it's expiration and directly create the view?

Again (and again) thank you for your hindsight!
Jean

[mingxwa]

Hi Jean,

Thanks for the insight (and sorry for the delay).

Yes, this returns a dangling proxy_view. weak_proxy::lock() yields a temporary owning proxy; you build a non‑owning view from it and return it. When the temporary dies at function exit, the view immediately dangles (same class of UB as returning a std::string_view into a destroyed temporary std::string).

A weak_proxy can check expiration, but it can't provide the lifetime a view needs. A view is only valid while some owning proxy stays alive.

I think the library should forbid this pattern. I can open a PR that disables constructing a proxy_view from an rvalue proxy (requiring an lvalue). Let me know if you're good with that direction.

[jeanga]

Good day Mingxin,

Again, I understand the logic but I wonder how the comparison with std::string & std::string_view compares with proxy's proxies.

As I understand them (or failed to), proxies and weak proxies are based on a reference counted mechanism (both weak and strong).
If so, as long as at least one strong proxy is kept alive, I can spawn as many weaks and views I want, these will remain valid.
Is that correct?
If so, if I guarantee that a strong owning proxy exists for this instance (via has_value() or operator bool()), I can get a valid view out of my weak proxy? In that case, creating a temporary strong proxy via lock() will increment & decrement the strong count in a 'non efficient' way?

Thank you for your insights, I'm trying to have a good understanding of the similarities (and differences) of proxies vs std::shared_ptr.
(and I liked proxy, weak_proxy, proxy_view) very much as they are very flexible for my use case:

• a container (dictionary) of types,
• inter-types references with weak proxies for 'longer term' references
• views for immediate "short lived" access (i.e. similar to what a .get() on a smart pointer would provide)

Happy to be corrected in my understanding as needed.
Thanks!

[mingxwa]

Hi Jean,

Thanks for the thoughtful follow‑up.

Core clarification: pro::proxy<Facade> does not imply reference counting. Its lifetime model is whatever handle you store, provided it meets the facade's structural constraints (copyability / relocatability / destructibility) plus any required skills.

So all of these are valid (facade does not request weak support):

struct Formattable : pro::facade_builder
    ::add_skill<pro::skills::format>
    ::build {};

int v = 123;
pro::proxy<Formattable> p1 = &v;                       // Non‑owning (borrowed)
pro::proxy<Formattable> p2 = std::make_unique<int>(v);  // Exclusive (owns via std::unique_ptr)
pro::proxy<Formattable> p3 = std::make_shared<int>(v);  // Shared (refcounted)
pro::proxy<Formattable> p4 = pro::make_proxy<Formattable>(v);        // Exclusive, small-object / no extra allocation
pro::proxy<Formattable> p5 = pro::make_proxy_shared<Formattable>(v); // Shared, custom shared impl (no weak)

Adding pro::skills::as_weak constrains admissible models to those that supply shared + weak ownership. Then the borrowed / unique / exclusive forms become ill‑formed, while shared forms remain:

struct FormattableWeak : pro::facade_builder
    ::add_skill<pro::skills::format>
    ::add_skill<pro::skills::as_weak>
    ::build {};

int v = 123;
pro::proxy<FormattableWeak> a = &v;                        // ERROR: raw pointer lacks shared+weak semantics
pro::proxy<FormattableWeak> b = std::make_unique<int>(v);   // ERROR: unique ownership only
pro::proxy<FormattableWeak> c = std::make_shared<int>(v);   // OK
pro::proxy<FormattableWeak> d = pro::make_proxy<FormattableWeak>(v);        // ERROR: exclusive
pro::proxy<FormattableWeak> e = pro::make_proxy_shared<FormattableWeak>(v); // OK (shared+weak capable)

So the earlier assumption "proxies and weak proxies are based on a refcounted mechanism" is only correct when you pick a shared/weak capable model (or require as_weak). Otherwise it might be borrowed, unique, intrusive, custom arena, etc.

proxy_view behaves exactly like a raw non‑owning pointer: it is valid iff the underlying object outlives it. Building a view from a temporary owning proxy is only safe if some other owner still keeps the object alive after the temporary is destroyed (same rule as forming a std::string_view from a std::string).

Direct answers:

"If so, as long as at least one strong proxy is kept alive, I can spawn as many weaks and views I want, these will remain valid. Is that correct?"

Yes. Provided the chosen lifetime model is shared/weak capable and at least one strong proxy remains alive, any number of weak proxies and views remain valid.

"If so, if I guarantee that a strong owning proxy exists … creating a temporary strong proxy via lock() will increment & decrement … in a 'non efficient' way?"

Correct. It's safe (given the guarantee) and just adds a transient atomic inc/dec, similar to a std::shared_ptr. A direct helper could elide that.

"How close is this to std::shared_ptr?"

Choosing a shared model makes weak/lock analogous to shared_ptr/weak_ptr. Otherwise pro::proxy can be unique / borrowed / custom.

Hope this clarifies the model succinctly. Happy to discuss further if anything's still fuzzy.

[jeanga]

Hi Mingxin,

Thank you very much for the detailed explanation.
I think I was too much heads down in my code and my specific context.
You are right to point that proxy supports much more than that and your examples here clarify that very clearly.

When you say "A direct helper could elide that.", you mean that my as_view() example:

pro::proxy_view<Identity> as_view(const pro::weak_proxy<Identity>& type)
{
    if (type)
        return type.lock();
    return {};
}

will be elided in release mode? If so, I'm happy with that ;-)
Won't #352 make this helper not compile?

Also, kudos for the flexibility of the skills and constraints concept introduced in v4.
They very clearly document the proxy intended use. That really gives us a lot of control/checks.

Thank you for a great library!
Jean

[mingxwa]

Hi Jean,

Thanks for the kind words!

a direct helper could elide that

I meant only in theory. One could imagine changing weak_proxy (it's just an alias of proxy) to expose something like try_get_view() that forms a proxy_view directly and skips the temporary strong proxy/refcount bump. That facility does not exist, and I don't think we should introduce it as a general utility.

Will my helper be elided in release mode?

No. The lock() you call must create a strong proxy; the atomic (or logical) refcount adjust happens. Only a different API (like the hypothetical try_get_view()) or a different underlying handle would avoid it.

Won't #352 make this helper not compile?

Yes. That change deliberately blocks constructing a proxy_view from an rvalue proxy so this pattern won't build.

About atomics: make_proxy_shared and std::shared_ptr both usually imply an atomic control block, but in this framework shared/weak doesn't have to be implemented that way. You can always plug in something like boost::intrusive_ptr or a custom non‑atomic single‑thread shared handle.