often used seldom defined terms: lvalue

An lvalue is a value that can be assigned to:

lvalue = rvalue;

It's short for "left value" or "lefthand value" and it's basically just the value on the left of the = sign, i.e. the value you assign something to.

As an example of what is not an lvalue (i.e rvalue only):

printf("Hello, world!\n") = 100; // WTF?

That code doesn't work because printf() (a function that returns an int) cannot be an lvalue, only an rvalue.

It's traditionally the left side of the "=" operator. However, with time, meaning of "lvalue"/"rvalue" changed. C++ added the term of a "non-modifiable lvalue" which is any lvalue that cannot assigned to: arrays and variables that are qualified with "const" are two examples. In C, you cannot assign to any rvalue (see below). Likewise, in C++, you cannot assign to rvalues that are not of some user defined class type.

You can say an "lvalue" is an expression that names an object which persists over time and occupies some location of storage. Whether or not you can assign to that expression is not important for that classification. A reference, in particular, is also an lvalue, because it has a name that persists over time. All the following are lvalues, because they all refer to named objects. Also note that a const does not have any effect on the lvalue-ness.

int a; lvalue: a;
       lvalue: ++a;
int a[2]; lvalue: a;
int &ra = a; lvalue: ra;
int *pa = &a; lvalue: *pa;

The term "rvalue" is used for things like literals and enumerator values and for temporaries that do not enjoy the fun of having a long life and are destroyed right away at the end of a full expression. For rvalues, not the aspect of persistence is important, but the value-aspect. Functions in C++ are lvalues, because they are persistent and they have an address, even though they are not objects. I've left them out in the above overview of lvalues, because it's easier to grasp lvalues when first only taking objects into account. All the following are rvalues:

enum { FOO, BAR }; rvalue: BAR;
int a[2]; rvalue: (a+1);
rvalue: 42;
int a; rvalue: a++; // refering to a temporary
struct mystruct { }; mystruct f() { return mystruct(); } rvalue: f();

Incidentally, often you have an lvalue, but an operator needs an rvalue. For example the binary builtin "+" operator adds two values. An lvalue expression first and for all specifies a location where a value first has to be read out. So when you add two variables, an "lvalue to rvalue" conversion takes place. The Standard says that the value contained in an lvalue expression is its rvalue result:

int a = 0, b = 1;
int c = a + b; // read values out of the lvalues of a and b. 

Other operators do not take rvalue, but lvalues. They don't read a value. An example is the address-of operator, &. You cannot take the address of an rvalue expressions. Some rvalues are not even objects: They do not occupy any storage. Examples are again, literals (10, 3.3, ...) and enumerator values.

How is that scary stuff useful?

Well it has several advantages to have the distinction of lvalue and rvalue

• Allowing the compiler to omit taking storage for rvalues and using registers/readonly memory for scalar values
• Flagging expressions as elusive: rvalues will not live long
  • Allows efficient copy semantics for the compiler internally and in c++1x also exposed to the programmer (see move semantics and rvalue references): We can steal away resources from rvalues that are going to be destroyed anyway.
• Allows to build rules upon that property
  • rvalues are not allowed to be generated from a yet uninitialized objects where an lvalues refers to. But lvalues may refer to uninitialized objects just fine
  • rvalues can never be polymorphic. Their static type must also be their dynamic type: Simplifies rules for the typeid operator.

... There is more to it, i feel it ...

Something that appears on the left hand side of an assignment i.e. something that can be assigned to.

Note that in C++ a function call may be an lvalue if:

int & func() {
   static int a = 0;
   return a;
}

then:

func() = 42;     // is legal (and not uncommon)

One of the best explanations I know of can be found in this article on RValue references.

another way to determine whether an expression is an lvalue is to ask "can I take its address?". If you can, it's an lvalue. If you can't, it's an rvalue. For example, &obj , &*ptr , &ptr[index] , and &++x are all valid (even though some of those expressions are silly), while &1729 , &(x + y) , &std::string("meow") , and &x++ are all invalid. Why does this work? The address-of operator requires that its "operand shall be an lvalue" (C++03 5.3.1/2). Why does it require that? Taking the address of a persistent object is fine, but taking the address of a temporary would be extremely dangerous, because temporaries evaporate quickly.