in function squareRef, we are doing dynamical memory allocation, where address of int object is stored in a variable dynamicAllocatedResult
so writing
*dynamicAllocatedResult will dereference pointer and get an integer value,

but what confuses me that function returns integer reference.

This line returns an integer value of 64

Code:

return *dynamicAllocatedResult;

And having

Code:

int & squareRef(int number)

equals to the

Code:

int* const squareRef(int number)

???

So if a function actually returns const pointer, why are we returning an integer value and not pointer which points to that integer value?

Is it because compiler does work for us so basically having this line:

You're over-complicating it, in my opinion. Think of it like this: A pointer is the position of a variable in memory. A reference (in C++ terms) is the variable itself. That's how I view it, and it works pretty well.

// Address Of An Object 0x2000
// Since it acts as a pointer
// I can assign address to reference variable ???
Class& obj = 0x2000; // same as Class* const obj = 0x1000;

No, it wouldn't. The type of the right hand operand would not be compatible with the type "reference to Class". The pointer version wouldn't work either for the same reason. You could get them to compile if you used reinterpret_cast (but for the reference you would need to dereference the pointer resulting from the cast).

When people say that a reference "acts as a const pointer", they mean that both point/refer to objects, and like how a const pointer cannot be changed to point to another object after initialisation, likewise a reference cannot be bound to another object after being created. Clearly, references and pointers have differences in syntax when declared and when used.

this is a pointer to the current object. The pointer points to the object. It doesn't point to an address. The value of a pointer is an address. Therefore, getAddressPointer returns a pointer to the current object.

this is a pointer to the current object. The pointer points to the object. Hence, *this is the object itself. Therefore, getAddress returns a reference to the current object.

Originally Posted by High Voltage

in function squareRef, we are doing dynamical memory allocation, where address of int object is stored in a variable dynamicAllocatedResult
so writing
*dynamicAllocatedResult will dereference pointer and get an integer value,

but what confuses me that function returns integer reference.

Since there is dynamic memory allocation, dynamicAllocatedResult points to an int object. Therefore, *dynamicAllocatedResult is the int object itself. Hence, a reference to that int object is returned. Using the object or a reference to the object, you could inspect the object's value, but the pointer points to the object, not its value, and likewise the reference refers to the object, not its value.

Originally Posted by High Voltage

So if a function actually returns const pointer, why are we returning an integer value and not pointer which points to that integer value?

Because the function is declared as returning a reference, not a const pointer, and what is actually returned is an integer object, to which the reference that is actually returned is bound. A reference is not a const pointer; a const pointer is not a reference. They are similiar in a way, a compiler might even implement references as if they were const pointers, but they are not the same thing.

Originally Posted by Bjarne Stroustrup (2000-10-14)

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

I don't ever recommend returning by reference. Especially when it looks like you're receiving a parameter by value and then returning a reference to that. In all likelihood, that's UB. Just return by value.

More fun with result passing

The C++ Witch clearly explains how things are working related to the original code.

Here is some more exploration on that last code snippet in the OP. Running the following code shows how both a return to ptr and a return to ref will preserve the address of the int object created on the heap:

*this is not 1000. this is a pointer to the class itself, hence *this is the class itself. The class is not an integer, hence that is not valid.

*this gives us object, but object is just a memory address, as it is any variable in C++, that is what I actually meant, am I right?

Originally Posted by MutantJohn

I don't ever recommend returning by reference. Especially when it looks like you're receiving a parameter by value and then returning a reference to that. In all likelihood, that's UB. Just return by value.

I am aware of that, just trying to understand references

Originally Posted by GReaper

You're over-complicating it, in my opinion. Think of it like this: A pointer is the position of a variable in memory. A reference (in C++ terms) is the variable itself. That's how I view it, and it works pretty well.

*this gives us object, but object is just a memory address, as it is any variable in C++, that is what I actually meant, am I right?

No, a reference is not a memory address. It's a type that may contain data and functions. Hence it does make sense to treat it as an "int".

If you're just trying to understand references, then just think of them as aliases. They share storage with the variable they reference. In essence, they're the same variables, but with different names. You don't need to complicate it any further.

Originally Posted by Adak

io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.

Originally Posted by Salem

You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

No, a reference is not a memory address. It's a type that may contain data and functions. Hence it does make sense to treat it as an "int".

If you're just trying to understand references, then just think of them as aliases. They share storage with the variable they reference. In essence, they're the same variables, but with different names. You don't need to complicate it any further.

So clearly the reference is not an int*. Using sizeof on classes is problematic because the compiler can add padding.

Well some people say that references act as they were pointers , and depending on the compiler they could be implemented as pointers or not, maybe your compiler doesn't implement it as pointers and therefore you get different sizeof?