You can get close to this with by using a lambda in C++. Generally, when you set a variable like

int x;

int y;

int z{x + y};

z will only be the result of x + y at that time. You'd have to do z = x + y; every time you change x or y to keep it update.

If you use a lambda though, you can have it capture what objects it should refer to, and what calculation should be done, and then every time you access the lambda it will give you the result at that point in time. That looks like

int x;

int y;

auto z = [&](){ return x + y; };

cin >> x;

cin >> y;

cout << z();

and now z() will have the correct value instead of the uninitialized garbage that the original code had.

If the computation is very expensive you can even add some caching to the lambda to make sure you aren't running the computation when you don't need to. That would look like

auto z = [&](){ static auto cache_x = x; 

                static auto cache_y = y; 

                static auto cache_result = x + y;

                if (x != cache_x || y != cache_y)

                {

                    cache_x = x; 

                    cache_y = y; 

                    cache_result = x + y;

                }

                return cache_result;

};

The closest you probably can get is to create a functor:

#include <iostream>



int main() {

    int x;

    int y;



    auto z = [&x, &y] { return x + y; }; // a lambda capturing x and y



    while(true) {

        std::cin >> x;

        std::cin >> y;

        std::cout << z() << "n";

    }

}

There are two chief techniques:

1. Deferred calculation - instead of z being a simple variable, make it a function which calculates the value on demand (see other answers for examples). This can be source-code transparent if z is some proxy object with implicit conversion to the required type (as in Aconcagua's answer).




2. Explicit notification of changes. This requires x and y to be observable types; when either changes value, then z updates itself (and notifies its observers if applicable).

The first version is usually preferred, but the second may be more appropriate if you need z to be an observable type.

This sounds like the XY problem (pun intended).

From the sound of it, you are not really writing code according to good object oriented practices. I would advise you not to use the "tricks" other people have suggested, but to actually learn how to make better use of OO structure.

Before I go into that, note that assignment is distinct from an equality relation. The = in C++ is assignment, which is not the same as the = in maths. There are some (but not many) programming languages that do support equality relations, but C++ is not one of them. The thing is, adding support for equality relations introduces a heap of new challenges, so it's not as simple as "why isn't it in C++ yet".

Anyway, in this case, you should probably be encapsulating your related variables in a class. Then you can use methods to obtain the "up-to-date" information. For example:

class Player {

    std::vector<int> inventory;

    int cash;

public:

    int inventory_total();

    int net_worth();

}



//adds up total value of inventory

int Player::inventory_total() {

    int total = 0;

    for(std::vector<int>::iterator it = inventory.begin(); it != inventory.end(); ++it) {

        total += *it;

    }

    return total;

}



//calculates net worth

int Player::net_worth() {

    //we are using inventory_total() as if it were a variable that automatically

    //holds the sum of the inventory values

    return inventory_total() + cash;

}





...





//we are using net_worth() as if it were a variable that automatically

//holds the sum of the cash and total holdings

std::cout << player1.net_worth();

I admit that adding this behaviour to a class is quite a bit more complicated than saying z = x + y, but it really is only a few extra lines of code.

That would be very annoying and error prone if you forgot to call the function somewhere.

In this case the object doesn't have a net_worth member variable, so you can't accidentally use it instead of calling the function.

1. You create a function for that.


2. You call the function with the appropriate arguments when you need the value.

int z(int x, int y)

{

   return (x + y);

}





int x;

int y;



// This does ot work

// int z{x + y};



cin >> x;

cin >> y;

cout << z(x, y);

You can define the following lambda z which always returns the current value of x+y because x and y are captured by reference:

DEMO

int main()

{

    int x;

    int y;



    const auto z = [&x, &y](){ return x+y; };



    std::cin  >> x; // 1

    std::cin  >> y; // 2

    std::cout << z() << std::endl; // 3



    std::cin  >> x; // 3

    std::cin  >> y; // 4

    std::cout << z() << std::endl; // 7

}

You can get what you're asking for by using macros:

{

    int x, y;

#define z (x + y)

    /* use x, y, z */

#undef z

}

The #undef is for a little sanity. For more sanity, don't use macros at all, and go with one of the other answers, and deal with the extra verbosity.

Although a class with a custom operator int would work in a lot of cases ... hmm.

So a big problem that I see with the lambda solutions provided is that z is calculated each time that it is inspected even if neither x nor y has changed. To get around this you really need to link these variables.
I would suggest doing that via class:

class foo {

    int x;

    int y;

    int z;

    void calculate() { z = (x + y) / 2; }

    friend istream& operator >>(istream& lhs, foo& rhs);

public:

    void set_x(const int param) {

        x = param;

        calculate();

    }

    int get_x() const { return x; }

    void set_y(const int param) {

        y = param;

        calculate();

    }

    int get_y() const { return y; }

    int get_z() const { return z; }

};



istream& operator >>(istream& lhs, foo& rhs) {

    lhs >> rhs.x >> rhs.y;

    rhs.calculate();

    return lhs;

}

This will recalculate z each time x or y is set. This is a good solution if you access z frequently, and x and y are set infrequently. If x and y are set frequently or calculate is expensive you might consider:

class foo {

    int x;

    int y;

    int z;

    bool dirty;

    void calculate() { z = (x + y) / 2; }

    friend istream& operator >>(istream& lhs, foo& rhs);

public:

    void set_x(const int param) {

        x = param;

        dirty = true;

    }

    int get_x() const { return x; }

    void set_y(const int param) {

        y = param;

        dirty = true;

    }

    int get_y() const { return y; }

    int get_z() const { 

        if(dirty) {

            calculate();

        }

        return z;

    }

};



istream& operator >>(istream& lhs, foo& rhs) {

    lhs >> rhs.x >> rhs.y;

    rhs.dirty = true;

    return lhs;

}

Note that I've included an extraction operator, so whichever you choose your code can turn into something as simple as:

foo xyz;



cin >> xyz;

cout << xyz.get_z();

What you're describing is late binding, which a compiled language like C++ can do only with difficulty. In an interpreted language, all you need is the ability to set z to an unevaluated expression and delay binding of z's value until the calculation is needed, typically signaled by a call to a function that forces the evaluation such as eval in Lisp. In my Expert System's rules language, I have not only eval but noeval, which protects its argument from one level of evaluation. That provides granular control over the binding, with some sub-expressions being evaluated (bound) and others not, if desired. This is not applicable to your scenario, but it sets the scene in terms of the language landscape.

Ok, let me at last write the right and only true answer to your stated question:

You can't.

You can't write z = x + y and then have all the code using z magically re-run whenever x or y changes.

So what can be done?

As mentioned in other answers, there are several patterns to express that you want changes of x and y to cause some updates, but in any case you need these updates to happen more or less explicitly.

Depending on a use case, you may:

• 
  

  Have the value recomputed anyway at all times this matters. E.g. if you write a game and redraw the screen every frame, than likely just making sure that you don't accidentally keep the z value between the frames is enough. Be aware of when your value can change and when it can't. Whether you use a function, a lambda, a class method, or just repeat the expression, is mostly esthetical decision. If available, this is the best approach, because it is fully transparent.

  
  
  

  For instance, in racing game you'd likely update your current speed at the beginning of the new tick computation, and then use the updated value when computing your car's movement, when redrawing the speed indicator, when creating the motion blur, and so on. You don't need any magic and not even a function, you can just use a variable, because you know your speed won't change during one frame.

  
  



• Call the update explicitly. Use it e.g. when you have a single widget you need to update. Downside is that you need to remember to call the update, which is somewhat brittle, but on the upside - it is dead simple. A middle ground is to have the update call integrated with a setter, making it kind of poor man's Observer implementation.




• Use Observer pattern (see also signals and slots, this is one way of implementing Observer). Use it e.g. when you have many widgets to update, or you create them dynamically. Avoid using it when one of the above works, they are way simpler.




• Use dedicated reactive programming library. As such stuff exists, I feel obliged to mention it. However, I honestly don't see any application where I would use it. It mostly seems like a complicated way to shoot your feet. The implicit updates are going to backfire, and you'll have to rewrite everything. Just don't, not in C++. What is important,: while this approach is closest to "magically update everything", it would impose constraints on how you write your code, and eventually you'll get one of the above solutions, just more complicated.