That is exactly how I feel.

________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
Sent: Monday, February 24, 2025 8:43 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Sebastian Wittmeier <wittmeier_at_[hidden]>
Subject: Re: [std-proposals] A non-owning but self zeroing smart pointer for single ownership


One could have such an API.

But IMHO that should be a separate proposal (as a separate class).

Not even shared_ptr tries to lock the object acess itself.

It would only solve a subset of use cases:

Sometimes more than one object takes part in such an transaction. If the lock is bound to the smart pointer, you suddenly would have more than one lock, and you would either activate each lock within each other, or you would only lock one or some of the objects.



One would separate the lock from the objects holding the data or put it as one of the member variables.



IMHO this functionality (lock within lambda) with its diverse use cases should rather be put into an extended scoped_lock proposal instead of a smart pointer one.



-----Ursprüngliche Nachricht-----
Von: Robin Savonen Söderholm via Std-Proposals <std-proposals_at_[hidden]>
Gesendet: Mo 24.02.2025 07:26
Betreff: Re: [std-proposals] A non-owning but self zeroing smart pointer for single ownership
An: std-proposals_at_[hidden];
CC: Robin Savonen Söderholm <robinsavonensoderholm_at_[hidden]>;

You could have an API along the lines of:
```

bool accessed = ptr.try_access([] (T& ref) { ref.function1(); ref.function2(); });

```

But I am not sure if we are getting any advantage over shared_ptr. Is there a reference implementation that can show how it works and how it solves the problem better/being more lightweight than shared_ptr?



// Robin

On Mon, Feb 24, 2025, 03:11 Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
On Sunday, 23 February 2025 19:40:38 Brasilia Standard Time Henry Miller via
Std-Proposals wrote:
> What this gives us that operator->() doesn't is direct knowledge when the
> function is done and thus an obvious place to release the lock.

That's hardly a correct assumption. No one would write:

  mutex.lock();
  ptr->function1();
  mutex.unlock();
  mutex.lock();
  ptr->function2();
  mutex.unlock();

Aside from the extra code this is generating and the possibly strain this is
putting on the cache traffic, the fact that you unlocked between function1 and
function2 implies the state may have completely changed. There may be cases
where this is an acceptable behaviour, but in the general case it won't be,
and that's why I said assuming the end of the expression is the correct place
to unlock.

In the majority of cases, I expect a lock to need to be held across multiple
invocations, so one must either get a locked proxy object that prevents the
state from changing underneath the object, or must explicitly lock themselves.
If the latter, an automatic lock by the class would be either superfluous or
would be a trigger for deadlocks.

--
Thiago Macieira - thiago (AT) macieira.info<http://macieira.info> - thiago (AT) kde.org<http://kde.org>
  Principal Engineer - Intel DCAI Platform & System Engineering
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
 Std-Proposals mailing list
 Std-Proposals_at_[hidden]
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals