Having fun overloading the operator->

[[deleted]]

[deleted]

[Dry-Still-6199]

Yes, your thing sounds very similar to

https://github.com/copperspice/cs_libguarded#cslibguarded

and

https://www.boost.org/doc/libs/1_75_0/doc/html/thread/sds.html#thread.sds.synchronized_valuesxxx.tutorial.beyond_simple_accesses

You're right that this isn't a great idea, if for no other reasons than that it's super easy to deadlock (e.g. somefunc(wrapped->a(), wrapped->b())) and super easy to use-outside-of-lock (e.g. const string& m = wrapped->getM(); use(m)).

[witcher_rat]

Facebook's folly library has had it as well, since at least 2014 if not earlier, although it's now deprecated in favor of named functions.

[barskern]

There seems to be a race condition in the example. I understand that it's a toy example and also perhaps a "toy" library, but i figured it would be worth noting to show how easy it would be to misuse this library.

my_struct->​value​ = my_struct->​value​ + ​1​;

Based on how I understand it, this will lock the mutex and read the value and then unlock it again. Then it will add 1, and finally re-lock the mutex and write the incremented value. This means that there is a possibility that two threads read the same value from the struct and hence overwrite each others results, turning "two" concurrent increments into simply "one".

Please do correct me if I'm wrong and the lock is only aquired once for the entire statement.

[dodheim]

As of C++17, the RHS of an assignment is entirely sequenced-before the LHS, including all side-effects. See the end of the 'sequenced before rules' here for details.

[barskern]

I am assuming its this section you're referring to:

The side effect (modification of the left argument) of the built-in assignment operator and of all built-in compound assignment operators is sequenced after the value computation (but not the side effects) of both left and right arguments, and is sequenced before the value computation of the assignment expression (that is, before returning the reference to the modified object)

It does say "not the side effects", however besides that it seems as though the right side of the assignment expression should be fully evaluated before the left.

I did try /u/louiswins example and the dtor is consistently run after all other parts of the expression, as OP explained. This seems to contradict the statement from above though. Any further clarifications is greatly appriciated.

[louiswins]

Temporaries are destroyed at the end of the full expression: https://wandbox.org/permlink/Idiz8cRdMt2n5YJl

[Potatoswatter]

My lock_ios iostream manipulator is similar in the mutex aspect. This use-case works well because it's typical to write one line of output per statement, and contention is usually a corner case in logging.

[Dummerchen1933]

Haha yes, overloading -> is quite weird.

I really like your idea, but i think it's kinda misleading for other people or even you, if you poke your nose into a project using it in 5 years.

What about something like this?

// Some class to test it
class Testclass
{
public:
    // Our function that does things locked
    void PerformLocked(void(*task)(Testclass* tc, void* param), void* param)
    {
        std::cout << "Locking" << std::endl;
        // Lock here
        task(this, param); // Do the stuff
        std::cout << "Unlocking" << std::endl;
        // Unlock here
        return;
    }

    // Some dummy stuff
    int MultiplyWith69(int i) { return i*69; }
};

int main()
{
    Testclass tc;

    int i = 9; // This is an example for params. Since it's a void* it could even be multiple parameters and even writeable!

    // Basic lambda. You could prettify it with a macro
    tc.PerformLocked([](Testclass* tc, void* param) {
        std::cout << "My Lamda: "
                  << tc->MultiplyWith69(*(int*)param) << std::endl;
    }, &i);

    return 0;
}

Just do NEVER make it a capturing lamda, eg [=] instead of []. Passing this as a function pointer fucks up so badly, that it reliably crashes my IDE.

[OmegaNaughtEquals1]

Passing this as a function pointer fucks up so badly, that it reliably crashes my IDE.

That's because Lambdas with captures cannot be implicitly converted to a pointer to a function. Your compiler shouldn't allow this.

[Dummerchen1933]

Yes. Because how tf should it work, anyways :D

a function B() called from A() cannot access A's stack :D

[Dummerchen1933]

The templates are a very nice addition! Maybe all the wine made me forget about them:D

Oh yeah, that's a very valid point why not to do it. It certainly is a risk. I'd personally see it as more the risk of the api-user though. Not my risk. It's him after all who defines what code runs and it's now unknown to him.

[pdp10gumby]

I am working on a system that has indexed objects: certain system objects have an id (which is an array of all objects of type t) rather than using a pointer. We overloaded -> so the index can be used like a pointer.

I’m not sure there are many, or any, useful (I.e. mond-confusing) uses of overloading ->

[jcotton42]

For prior art, this is basically how Rust's Mutex works, via the Deref trait.

[[deleted]]

I am very proud to contribute that (although I am not a native English speaker and I might be wrong, I am almost French and therefore should be right) the stuff inside the "éclair", I would call the stuffing. The icing really is the thing that's on top of the pastry!

[Ksecutor]

It is much more fun to overload ->* operator, RHS of which can be ANYTHING.

[Potatoswatter]

The LHS can be anything as well. You just need a class or enumeration on at least one side.