Kdjykuj

You mean something like this:

class Z

{

    int& x;

    int& y;

public:

    Z(int& x, int& y) : x(x), y(y) { }

    operator int() { return x + y; }

};

The class delays calculation of the result until casted as int. As cast operator is not explicit, Z can be used whenever an int is required. As there's an overload of operator<< for int, you can use it with e. g. std::cout directly:

int x, y;

Z z(x, y);

std::cin >> x >> y;

if(std::cin) // otherwise, IO error! (e. g. bad user input)

    std::cout << z << std::endl;

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.

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);

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.

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

}

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();

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.