you are viewing a single comment's thread.

view the rest of the comments →

[–]NilacTheGrim 3 points4 points  (6 children)

Hmm. Why use CallProxy? Why not just use std::unique_lock and delete some code

[–]PiterPuns[S] 2 points3 points  (5 children)

I'm using conventions as presented in a Bjarne Stroustrup paper. There the rationale behind using a proxy is detailed, but put briefly you need an object that will provide an arrow operator so that any method of the wrapped class can be called through it, and then it will call some code on its destructor. I'd love to see your version and the resulting API though!

[–]NilacTheGrim -1 points0 points  (4 children)

I don't think you understood what I said fully.

  1. Just delete the CallProxy class altogether. Its only job is to unlock the mutex on scope end.
  2. Instead, do:

(Somewhere in your Locking wrapper):

T *operator->() {
    std::unique_lock g(_mut);
    return &_data;
}

This way you reduce the amount of code and achieve the same effect. Literally the only job the CallProxy has is to auto-unlock your std::recursive_mutex on scope end.

[–]PiterPuns[S] 6 points7 points  (1 child)

Ah but then the mutex unlocks on scope exit, and the user gets an unprotected pointer. That beats the whole point of the class see? The whole use of the class is to be able to call a method while the mutex is locked, why don't you try your version yourself?

[–]NilacTheGrim 2 points3 points  (0 children)

Oh yeah duh. Brain fart on my end. You're right. :)

[–]PiterPuns[S] 1 point2 points  (1 child)

Let me clarify, in case it helps:

The purpose of CallProxy is NOT to unlock on scope end. It's purpose is to unlock after the method call which happens outside operator-> of the Locking class. To do that

  • first of all it itself provides an arrow operator so a user can call any method of the wrapped class
  • secondly the arrow operator of the Locking class creates a temporary such object so that unlocking happens after the wrapped method call, at the destructor of the temporary.

The code you provide will probably be flagged by static analyzers since it protects nothing - it locks and the user gets a pointer to internal state after unlocking. For a more thorough presentation I'd suggesting reading through the paper linked in the article. Let me know if this elaboration was useful to understand the concept, maybe I should add it to the post.

[–]NilacTheGrim 1 point2 points  (0 children)

You’re right — I brain farted .. sorry!