pointer

[Moschops]

Fortunately, this thread is already lumbering on in the guise of another, newer thread. It will never die.

[Gaminic]

I tried to set up a test, but I'm not certain if it's valid:

struct crefTest {
	crefTest() { printf("Constructor.\n"); }
	~crefTest() { printf("Destructor.\n"); }
};
crefTest f() { return crefTest(); }
int main() {
	if(1) { const crefTest &t = f(); }
	if(1) { crefTest t = f(); }
	return 0;
}

Both cases only print one Constructor and Destructor pair (tested separately as well as together). Is that compiler optimization at work, or did I oversimplify my test?

[Cubbi]

Wikipedia wrote:

Lvalues are values that have addresses being programmatically accessible

This describes a concept through one of its properties. Lvalue is an expression that evaluates to the identity of a non-temporary object. One of its properties is that its address may be taken.

hamsterman wrote:

to store an lvalue, means to store an address.

Yes, if you want to *store* an lvalue in some containing object, you would have to obtain its address (which is an rvalue) and assign that address to that containing object (which has to have a suitable pointer type). Which is why I always say "pointer holds a reference" (or doesn't, if it's nullable).

That makes pointers a requirement in many programming tasks, e.g. the design of trees, lists, and other data structures.

But since C++ (unlike C) supports pass-by-reference and since C++ (also unlike C) allows binding of additional names to objects, many other programming tasks do not require address juggling. Of course they can be done by chaining address-of/assign to pointer/copy pointer/dereference and, if written well, will compile to identical machine code, using pointers introduces unnecessary semantic complexity to something the language offers directly.

[Moschops]

I tried to set up a test, but I'm not certain if it's valid:

Hang on. Head hurting... do we need to make a copy constructor with a cout <<"Copying" in it?

[Gaminic]

Not much point in copying if only one object is ever created, is there? I'll test it just for giggles.

[edit]
Added these lines:

crefTest(const crefTest& _C) { printf("Copy-constructor.\n"); }
crefTest operator=(const crefTest& _C) { printf("Copying.\n"); }

They are never printed.
[edit2]
Also tried adding a random member variable (an int that is printed at the destructor, and copied+printed in the copy-constructor and the assignment operator. Still, only a single constructor and destructor seen.

[Moschops]

I think we're seeing return value optimisation; the wiki page has some nice example code that doesn't address exactly this, but is helpful. http://en.wikipedia.org/wiki/Return_value_optimization

[Gaminic]

Does that kick "the most important const" in the testicles, or will it still have its purposes in more complicated examples?

[Moschops]

It won't compile without that const (except on Visual Studio, arghh, this whole thing just won't stand still!), so even if not important anymore it's still const :) As for the necessity of the whole thing, I would have to dig out exactly how these people decide that RVO is applicable or not. If they'll happily do it even when the copy constructor has some way cool side-effect (which to be fair is an expressly allowed option they have, so if my way cool side-effects get skipped I've only got myself to blame), I'm struggling to work out when they won't do it.

It being RVO is a bit of a guess as it is; anyway, there is some hope. This article http://drdobbs.com/cpp/184403855 indicates that with some more complicated code, the compiler will just give up on RVO and do it the slow way.