Back to basics

[twoscoops]

OK, back to some really basic stuff. Would someone be kind enough to explain this program, it's part of the beginners c++ tutorials !! (I said it was basic)

TIA.

// vectors: overloading operators example
#include <iostream>
using namespace std; // OK
class CVector { // OK
public: // OK
int x,y; // OK
CVector () {}; // OK
CVector (int,int); // OK
CVector operator + (CVector); // OK (I think)
}; // OK
CVector::CVector (int a, int b) { // OK
x = a; // OK
y = b; // OK
} // OK
CVector CVector::operator+ (CVector param) { // OK
CVector temp; // OK
temp.x = x + param.x; // OK Understood in the context of c = a + b is a.operator + (b);
temp.y = y + param.y; // OK Understood in the context of c = a + b is a.operator + (b);
return (temp); // Won't this local object get destroyed now?
}
int main () { // OK
CVector a (3,1); // OK
CVector b (1,2); // OK
CVector c; // OK
c = a + b; // Don't understand hasn't temp been destroyed?
cout << c.x << "," << c.y; // OK
return 0; // OK
}




Equally confused :-

// this
#include <iostream>
using namespace std;
class CDummy {
public:
int isitme (CDummy& param); // isitme takes a reference to a CDummy as a paramter ?
};

int CDummy::isitme (CDummy& param) // isitme takes a reference to a CDummy as a paramter ?
{
if (&param == this) return true; // if the address of the reference == the address of the object ?? Eh?
else return false; // Return false on an int?
}
int main () {
CDummy a;
CDummy* b = &a;
if ( b->isitme(a) )
cout << "yes, &a is b";
return 0;
}

[jsmith]

return (temp); // Won't this local object get destroyed now?

Yes, but it is copied before it is destroyed.

c = a + b; // Don't understand hasn't temp been destroyed?

It has, but you can think of it as being destroyed after it is copied to c.

int isitme (CDummy& param); // isitme takes a reference to a CDummy as a paramter ?

Yes. What's your question?

if (&param == this) return true; // if the address of the reference == the address of the object ?? Eh?

This would happen, for example, if you called it this way:

CDummy dummy;
dummy.isitme( dummy );

This type of check is often used to test for self-assignment:

Foo f;
f = f;  // self-assignment 

because often times user-defined assignment operators are coded in such a way that it will blow up if you attempt self assignment.

else return false; // Return false on an int?

Bad programming style on the part of the author. The return type should be bool, not int. But it works because C++ allows implicit conversion of bool back to int (false is converted to 0, true is converted to a value that is not 0).

[Disch]

please use code tags ^^

CVector CVector::operator+ (CVector param) { // OK
CVector temp; // OK
temp.x = x + param.x; // OK Understood in the context of c = a + b is a.operator + (b);
temp.y = y + param.y; // OK Understood in the context of c = a + b is a.operator + (b);
return (temp); // Won't this local object get destroyed now?  

Yes, the local 'temp' is destroyed, but because the return value is a CVector (ie: by value, not by reference), a copy of it is made.

If the return value were CVector* or CVector&, then you are correct in thinking this would be a problem, because 'temp' would be destroyed once the function exists, and the returned pointer/reference would be bad

int CDummy::isitme (CDummy& param) // isitme takes a reference to a CDummy as a paramter ? 

Yes. A reference is similar to a pointer, but with different syntax. This allows the called function to manipulate the passed object, rather than it getting a copy of the object. It might be best to think of a reference as BEING the referred object, not simply pointing to it.

Simple example:

void func(int& foo)
{
  foo = 5;
}

int main()
{
  int v = 0;
  func(v);
  cout << v;  // outputs '5' because 'func' changed 'v'

  return 0;
}

[codee]if (&param == this) return true; // if the address of the reference == the address of the object ?? Eh?[/code]

'param' is the passed object. Therefore '&param' is the address of the passed object (not the address of the reference).

else return false; // Return false on an int?

You're right. That's stupid. The function should return a bool.

bools can be implicitly cast to integers, though. 'false' == 0 and 'true' == 1. But ew. That example sucks.



EDIT -- blah I'm too slow!

[twoscoops]

If the return value were CVector* or CVector&, then you are correct in thinking this would be a problem, because 'temp' would be destroyed once the function exists, and the returned pointer/reference would be bad

Thanks, that makes sense, what was I thinking? (Not much)

I still don't undetand this though.

The declaration of the CDummy::isitme takes a reference to a CDummy as below.


int CDummy::isitme (CDummy& param) // isitme takes a reference to a CDummy as a paramter ?


'param' is the passed object. Therefore '&param' is the address of the passed object (not the address of the reference).

I don't understand why param is now not a reference any more.


Ok, lets, wind back a bit I'm a C programmer as per your example :- In C


void func(int *foo) // Function takes a pointer address
{
*foo = 5; // dereference the pointer and assign value of 5
}

int main()
{
int v = 0;
func(&v); // Call function with address of v
cout << v; // outputs '5' because 'func' changed 'v' // we'll forget the printf!

return 0;
}


Whereas :-


void func(int& foo) // function takes a reference to foo
{
foo = 5; // foo is now no longer a reference but the actual "object" dereference implied?
}

int main()
{
int v = 0;
func(v); // Called with object, but function expecting a reference, implicit conversion here?
cout << v; // outputs '5' because 'func' changed 'v'

return 0;
}

[jsmith]

References do not have to be pointers, but in reality all compiler implementations make them pointers. That said, references are pointers that allow you to access the "pointed-to" contents without using pointer notation.
Your confusion is exactly the benefit of using references.

[twoscoops]

I always thought a reference was a const pointer to an object. I "think" its the implied dereferencing that gets me.

[firedraco]

Like it has been said, you can just think of a "reference" as just being "the" object (no pointers or anything).