Avatar of phoffric
phoffric
 asked on

lvalue c++ question

If a1, a2, and a3 are of a user defined type, T, and you overload the * operator for T, then it may be possible to write:

(a1*a2) = a3;

This looks non-sensical. Yet, it compiles and runs, but I think the statement behaves like a noop.

Could you show me from the C++ standard how this can be? I thought the LHS of assignment operator is an lvalue. But a1*a2 does not look like an lvalue to me. I don't see what possible usefulness the above statement could have.
C++Programming Theory

Avatar of undefined
Last Comment
phoffric

8/22/2022 - Mon
ASKER CERTIFIED SOLUTION
jkr

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question
phoffric

ASKER
Thanks for your response.

From your remark, I got the impression that function returned values are temporary values which are also lvalues. Could you please show me in the C++ standard where this is and why it is necessary? Is it so that we can have statements like:   foo() = some-value; ?

There appears to be a difference between temporary values generated from User Defined Types and Built-In Types, as noted in this program:
template <class T>
class Lvalues {
public:
  Lvalues(T i) : val(i) {}
  T sumT(T arg) { (arg+val) = val; return (arg+val); }
  T val;
};

int main() {
  Lvalues<int> b1(4), b2(5), b3(6);
  Lvalues<string> a1("4"), a2("5"), a3("6");
  a1 = a2.sumT("12");  // OK, no compiler error
  cout << a1.val;
//  b1 = b2.sumT(12);
}

Open in new window

The line b1 = b2.sumT(12); has the compiler error: lvalue required as left operand of assignment. When commented out, the program gives the expected result: 125.

Why should it work for UDT, but not for Built-In-Type?
SOLUTION
jkr

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question
phoffric

ASKER
Ok, thanks for the comments. I will accept that you are representing the standard reasonably well. Thanks again, and Happy Holidays to you.
jkr

I hope I am (not 100% sure, but 90% should be OK - focusing on that very "temporary object"), but trying my best, and my hoilday wishs go back in your direction ;o)
Your help has saved me hundreds of hours of internet surfing.
fblack61
jkr

Loking at that after a few days, let me make one correction:

I wrote

But every operation that returns an object, that object is assumed to be assignable (which I assume to be "OO-101"), thus being fit for being taken as an L-value - and that's where the conundrum starts.
and that should have been
every operation that returns a non-const object
- maybe 'constness' could be the key to that very conundrum here?
phoffric

ASKER
>> every operation that returns a non-const object
Right, I figured that was what you meant. Thanks for clarifying.
Happy New Year!