reference type methods

[Ruben]

Why would a method that is defined to return a reference such as with the
operator overload of [], operator[],

href& operator[](int index){
return _array[index];
}

not cause a type mismatch compiler error?

Ruben

--
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software

So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998

http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

"Yeah - I write Free Software...so SUE ME"

"The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."

"I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."

© Copyright for the Digital Millennium

[Ian Collins]

Ruben wrote:

Why would a method that is defined to return a reference such as with the
operator overload of [], operator[],

href& operator[](int index){
return _array[index];
}

not cause a type mismatch compiler error?

Why should it? Assuming _array is an array of href, it just returns a
reference to an href.

--
Ian Collins.

[Ruben]

On Mon, 14 Jul 2008 22:11:19 +1200, Ian Collins wrote:

Ruben wrote:

>Why would a method that is defined to return a reference such as with
the operator overload of [], operator[],

href& operator[](int index){
return _array[index];
}
}
not cause a type mismatch compiler error?

Why should it? Assuming _array is an array of href, it just returns a
reference to an href.

hmmm

the symbol array would not be a reference
it would be defined

private:
int _array[default_size];

This comes up from a text book, and I found it puzzling.

Ruben
--
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software

So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998

http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

"Yeah - I write Free Software...so SUE ME"

"The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."

"I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."

© Copyright for the Digital Millennium

[Ian Collins]

Ruben wrote:

On Mon, 14 Jul 2008 22:11:19 +1200, Ian Collins wrote:

>Ruben wrote:

>>Why would a method that is defined to return a reference such as with
the operator overload of [], operator[],

href& operator[](int index){
return _array[index];
}
}
not cause a type mismatch compiler error?

Why should it? Assuming _array is an array of href, it just returns a
reference to an href.

hmmm

the symbol array would not be a reference
it would be defined

private:
int _array[default_size];

Yes, but _array[index] in an int. I can only guess that href is a
typedef alias for int. The function returns a reference to that int.

--
Ian Collins.

[Ruben]

On Mon, 14 Jul 2008 22:30:24 +1200, Ian Collins wrote:

Ruben wrote:

>On Mon, 14 Jul 2008 22:11:19 +1200, Ian Collins wrote:

>>Ruben wrote:
Why would a method that is defined to return a reference such as with
the operator overload of [], operator[],

href& operator[](int index){
return _array[index];
}
}
not cause a type mismatch compiler error?

Why should it? Assuming _array is an array of href, it just returns a
reference to an href.

hmmm

the symbol array would not be a reference it would be defined

private:
int _array[default_size];

Yes, but _array[index] in an int. I can only guess that href is a typedef
alias for int. The function returns a reference to that int.

Ah - your right. I made a mistake and it confused you. I'm so sorry

int& operator[](int index){
return _array[index];
}
But I still am not sure why it doesn't cause a type mismatch error.

Ruben

--
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software

So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998

http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

"Yeah - I write Free Software...so SUE ME"

"The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."

"I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."

© Copyright for the Digital Millennium

[Ian Collins]

Ruben wrote:

On Mon, 14 Jul 2008 22:30:24 +1200, Ian Collins wrote:

>Yes, but _array[index] in an int. I can only guess that href is a typedef
alias for int. The function returns a reference to that int.

Ah - your right. I made a mistake and it confused you. I'm so sorry

int& operator[](int index){
return _array[index];
}

But I still am not sure why it doesn't cause a type mismatch error.

Because there isn't one.

The type of _array[index] is int. The function returns a reference to
an int, so there isn't any mismatch.

--
Ian Collins.

[Ruben]

On Mon, 14 Jul 2008 23:26:07 +1200, Ian Collins wrote:

>}
But I still am not sure why it doesn't cause a type mismatch error.

Because there isn't one.

The type of _array[index] is int. The function returns a reference to an
int, so there isn't any mismatch.

Thanks

That is the part I don't satisfactorly understand. Why is it not
returning the rvalue of the array element.

Why is it different than this

int x, y[10] = {1,2,3,4,5,6,7,8,9,10};

x = y[3];

I would think the requested return value doen't match the method
definition and I'd have to return something like this

return &i[index];

Ruben

--
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software

So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998

http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

"Yeah - I write Free Software...so SUE ME"

"The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."

"I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."

© Copyright for the Digital Millennium

[Ian Collins]

Ruben wrote:

On Mon, 14 Jul 2008 23:26:07 +1200, Ian Collins wrote:

>>}
But I still am not sure why it doesn't cause a type mismatch error.

Because there isn't one.

The type of _array[index] is int. The function returns a reference to an
int, so there isn't any mismatch.

Thanks

That is the part I don't satisfactorly understand. Why is it not
returning the rvalue of the array element.

That would be const reference.

Why is it different than this

int x, y[10] = {1,2,3,4,5,6,7,8,9,10};

x = y[3];

How is it different? It is more like

int& x = y[3];

I would think the requested return value doen't match the method
definition and I'd have to return something like this

return &i[index];

No, you are out by one level of indirection. &i[index] takes the
address of i[index] and yields a pointer to int.

It looks like you should do some background reading on references and
pointers, particularly their differences.

--
Ian Collins.

[Ruben]

On Mon, 14 Jul 2008 23:36:45 +1200, Ian Collins wrote:

How is it different? It is more like

int& x = y[3];

>I would think the requested return value doen't match the method
definition and I'd have to return something like this

return &i[index];

No, you are out by one level of indirection. &i[index] takes the address
of i[index] and yields a pointer to int.

It looks like you should do some background reading on references and
pointers, particularly their differences.

agreed. I understand pointers. I've never seen references at all until
C++ and the texts aren't defining them well.

One thing I know is that is an element of an int array is accessed through
either indirection

*(p +4);

or though the array

a[10];

I get a return value of an integer.

But it seems that if I use a reference on the left of the assignment

int& i = a[];
int b[10];

i = b[6];

I seem to get an entirely different behavior.
Ruben

--
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software

So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998

http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

"Yeah - I write Free Software...so SUE ME"

"The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."

"I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."

© Copyright for the Digital Millennium

[Ruben]

On Mon, 14 Jul 2008 23:36:45 +1200, Ian Collins wrote:

Ruben wrote:

>On Mon, 14 Jul 2008 23:26:07 +1200, Ian Collins wrote:

>>>But I still am not sure why it doesn't cause a type mismatch error.

Because there isn't one.

The type of _array[index] is int. The function returns a reference to
an int, so there isn't any mismatch.

Thanks

That is the part I don't satisfactorly understand. Why is it not
returning the rvalue of the array element.

That would be const reference.

>Why is it different than this

int x, y[10] = {1,2,3,4,5,6,7,8,9,10};

x = y[3];

How is it different? It is more like

int& x = y[3];

>I would think the requested return value doen't match the method
definition and I'd have to return something like this

return &i[index];

No, you are out by one level of indirection. &i[index] takes the address
of i[index] and yields a pointer to int.

Yes but i[index] returns a literal integer. In fact, I don't know of any
way of returning a varriable, only the data that a symbolic variable
refers to.

I do know how to return an address of a variables assigned space, though a
pointer, like in scanf for example.

return i[index] isn't an lvalue. Yet when the fuction is defined as
returning a reference, it seems to have a seperate syntax unrelated to
the rest of a references implimentation. The only way I know of returning
an actually reference...actually I don't know a way because even under
this circumstance

int =y =3, z;
int & x = y;

z = x; //STILL an RVALUE assigned and copied to z

so

return x;//should still be an rvalue returned (unless you return a point)

This seems to be a seperate property of references.

Ruben

>
It looks like you should do some background reading on references and
pointers, particularly their differences.

--
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software

So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998

http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

"Yeah - I write Free Software...so SUE ME"

"The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."

"I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."

© Copyright for the Digital Millennium

[Lionel B]

On Mon, 14 Jul 2008 20:24:22 -0400, Ruben wrote:

On Mon, 14 Jul 2008 23:36:45 +1200, Ian Collins wrote:

>>
It looks like you should do some background reading on references and
pointers, particularly their differences.

agreed. I understand pointers. I've never seen references at all until
C++ and the texts aren't defining them well.

Perhaps the easiest way to think of a reference is as an "alias" (i.e.
another name) for the same variable.

int x; // declares a variable x; i.e. a location in memory that we
// may refer to as x

x = 4; // store 4 at that location

int& y = x; // define the "alternative name" y for the location x

Now x and y refer to the same location in memory - i.e. the same
variable. So for example:

int z;

then both of:

z = x;

and:

z = y;

would store the value 4 in z, while:

std::cout << x;

std::cout << y;

will both output 4

[In particular, don't confuse the *concept* of a reference with its
*implementation* (which is irrelevant to its semantics). References may
well be implemented by your compilers as pointers, but then again they
may not be, so best not to even think about it...]

HTH,

--
Lionel B

[Ian Collins]

Ruben wrote:

On Mon, 14 Jul 2008 23:36:45 +1200, Ian Collins wrote:

>Ruben wrote:

>>>
return &i[index];

No, you are out by one level of indirection. &i[index] takes the address
of i[index] and yields a pointer to int.

Yes but i[index] returns a literal integer. In fact, I don't know of any
way of returning a varriable, only the data that a symbolic variable
refers to.

I do know how to return an address of a variables assigned space, though a
pointer, like in scanf for example.

return i[index] isn't an lvalue.

But i[index] is.

As is n in

int &n = i[index];

so if you break the function down to

int &n = i[index];
return n;

>
int =y =3, z;
int & x = y;

z = x; //STILL an RVALUE assigned and copied to z

But what about

x = 42;?

--
Ian Collins.

[James Kanze]

On Jul 15, 5:12 am, Ruben <[e-mail]:

On Mon, 14 Jul 2008 23:36:45 +1200, Ian Collins wrote:

Ruben wrote:

On Mon, 14 Jul 2008 23:26:07 +1200, Ian Collins wrote:
But I still am not sure why it doesn't cause a type
mismatch error.
Because there isn't one.
The type of _array[index] is int. The function returns a
reference to an int, so there isn't any mismatch.

That is the part I don't satisfactorly understand. Why is
it not returning the rvalue of the array element.

That would be const reference.

That's not really true either. A const reference is also an
lvalue.

Why is it different than this

int x, y[10] = {1,2,3,4,5,6,7,8,9,10};

x = y[3];

How is it different? It is more like

int& x = y[3];

I would think the requested return value doen't match the method
definition and I'd have to return something like this

return &i[index];

No, you are out by one level of indirection. &i[index]
takes the address of i[index] and yields a pointer to int.

Yes but i[index] returns a literal integer.

No. By definition, i[index] is *(i + index), and the results of
a dereference operator is always an lvalue. There's no literal
involve here at all.

In fact, I don't know of any way of returning a varriable,
only the data that a symbolic variable refers to.

You can't return a variable, however... A certain number of
expressions result in lvalues, both the name of a variable and
dereferencing, for example. An lvalue refers to an object; if
you need the value, the compiler automatically applies an lvalue
to rvalue conversion, but only if you need the value. You can
take the address of an lvalue, and you can use it to initialize
a reference. If you use it to initialize a reference, the
reference refers to the object the lvalue expression referred
to.

(You can also use a rvalue to initialize a reference to const.
In that case, the compiler automatically generates a temporary
object of the required type, and initializes the reference to
refer to it.)

I do know how to return an address of a variables assigned
space, though a pointer, like in scanf for example.

return i[index] isn't an lvalue.

i[index] is an lvalue.

Yet when the fuction is defined as returning a reference, it
seems to have a seperate syntax unrelated to the rest of a
references implimentation. The only way I know of returning
an actually reference...actually I don't know a way because
even under this circumstance

int =y =3, z;
int & x = y;

z = x; //STILL an RVALUE assigned and copied to z

x is an lvalue. There's an implicit lvalue to rvalue conversion
which occurs here.

so

return x;//should still be an rvalue returned (unless you return a point)

This seems to be a seperate property of references.

It has nothing to do with references per se. You seem to be
having problems with which expressions are lvalues, and which
aren't. From memory: id expressions (the name of an object),
subscripting, dereferencing, prefix increment and decrement, and
the assignment expression, are lvalues. Other expressions may
be lvalues in certain cases: a function call or a type
conversion (cast) is an lvalue if and only if the return
type/converted to type is a reference, and there are likely a
few special cases I've forgotten.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Ruben]

On Tue, 15 Jul 2008 02:32:48 -0700, James Kanze wrote:

>
No. By definition, i[index] is *(i + index), and the results of a
dereference operator is always an lvalue. There's no literal involve here
at all.

Can you show me that definition, because I've had a whole other
conversation in the comp.lang.c that was supported by compiler output and
the C FAQ that proved this to be untrue.

An array object is not just a simple pointer. And when I've worked with
bearwolf cluster programming, this is explicitely clear.
With regard to the lvalue of a valuable's data,
your saying that

int x = 10;

retunr x;

that returns an lvalue? 10 is not an lvalue. So I've confused. If this
was true then I would be able to do with

int f(x);

f(x) = 5; //that can't be done

I think we are mixing up the data stored in variables from the variables
themselves.
Ruben
--
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software

So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998

http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

"Yeah - I write Free Software...so SUE ME"

"The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."

"I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."

© Copyright for the Digital Millennium

[Ruben]

On Tue, 15 Jul 2008 20:38:44 +1200, Ian Collins wrote:

Ruben wrote:

>On Mon, 14 Jul 2008 23:36:45 +1200, Ian Collins wrote:

>>Ruben wrote:

return &i[index];

No, you are out by one level of indirection. &i[index] takes the
address of i[index] and yields a pointer to int.

Yes but i[index] returns a literal integer. In fact, I don't know of
any way of returning a varriable, only the data that a symbolic variable
refers to.

I do know how to return an address of a variables assigned space, though
a pointer, like in scanf for example.

return i[index] isn't an lvalue.

But i[index] is.

As is n in

int &n = i[index];

so if you break the function down to

int &n = i[index];
return n;

Yes this is what I ment prior with the address of operator. Here your in
theory possibly at least returning a reference and the types would match.

>

>int =y =3, z;
int & x = y;

z = x; //STILL an RVALUE assigned and copied to z

But what about

x = 42;?

That is a clearer rvalue being assigned, this time to the references
aliased variable.

--
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software

So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998

http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

"Yeah - I write Free Software...so SUE ME"

"The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."

"I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."

© Copyright for the Digital Millennium

[James Kanze]

On Jul 15, 1:37 pm, Ruben <[e-mail]:

On Tue, 15 Jul 2008 02:32:48 -0700, James Kanze wrote:

No. By definition, i[index] is *(i + index), and the
results of a dereference operator is always an lvalue.
There's no literal involve here at all.

Can you show me that definition, because I've had a whole
other conversation in the comp.lang.c that was supported by
compiler output and the C FAQ that proved this to be untrue.

I think you're confusing things. An array is not a pointer,
that's certain. But an expression with an array type will
implicitly convert to a ponter. And since the [] is only
defined for pointers (not for arrays), that's what happens here.

See section 4.2 in the C++ standard for the array to pointer
conversion, and 5.2.1 for the definition of the [] operator (or
sections 6.3.2.1 and 6.5.2.1 respectively in the C standard).

An array object is not just a simple pointer. And when I've
worked with bearwolf cluster programming, this is explicitely
clear.

Who said it was? But since the [] operator is not defined for
array types, the array converts to a pointer.

With regard to the lvalue of a valuable's data,

your saying that

int x = 10;

retunr x;

that returns an lvalue? 10 is not an lvalue. So I've
confused. If this was true then I would be able to do with

No. The expression x is an lvalue. It is used to initialize
the return value (which can be thought of as a hidden temporary
object), which involves an lvalue to rvalue conversion.

And of course, 10 is not an lvalue, but 10 isn't x.

int f(x);

f(x) = 5; //that can't be done

Of course not. A function expression is an lvalue if and only
if its return type is a reference.

I think we are mixing up the data stored in variables from the
variables themselves.

I think you really need a basic course in C/C++ expressions.
Lvalue-ness applies to expressions, not values. And because of
the lvalue to rvalue conversion, an expression which is an
lvalue can be used where ever an rvalue is required. (The
reverse is not true, of course.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Eugene Vernikovskiy]

I think you can simplify things with references a lot if you realize
that there is no significant difference between references and pointers.

For example

int iX = 10;

int& rX = iX;
int* pX = &iX;

In both cases we save an address of the variable iX in a reference or in
a pointer. So

rX = 5; // This makes the expression iX == 5 true
*pX = 6; // This makes the expression iX == 6 true

Then think about the function

int* fPointer() { return &iX; }

By all means you realize that

*fPointer() = 5; // This makes the expression iX == 5 true;

Why are you surprized that the following is correct?

int& fRef() { return iX; }

fRef() = 6; // This makes the expression iX == 6 true;

There is no difference between rX and fRef() in this case. fRef returns
not the rValue but the lValue which can be modified (the same way as the
pointer value can be used to modify the value it is referencing to).

Now if you accept that a[n] = 5 puts the value 5 into the n+1's element
of the array you should accept the syntax below:

int& f( int n ) { return a[n]; }
f(n) = 5;

Obviously f(n) and a[n]is just the same thing. You can look on the
pointers if you want, it is just the same:

int* f( int n ) { return a + n; } // &a[n] and a + n is the same
*f(n) = 5;
P.S.
a[5] cannot be an r-value. It is an l-value. Otherwise a[5] = 6 is a
syntax error.

[James Kanze]

On Jul 17, 5:10 am, Eugene Vernikovskiy
<[e-mail]:

I think you can simplify things with references a lot if you
realize that there is no significant difference between
references and pointers.

Oh yes there are. To begin with, references aren't objects, and
pointers are. What you probably meant to say is that references
behave very much like automatically dereferenced pointers.

For example

int iX = 10;

int& rX = iX;
int* pX = &iX;

In both cases we save an address of the variable iX in a
reference or in a pointer.

That's one possible implementation. But the semantics of
references have been carefully specified so that they could be
implemented as pointers. (In such direct cases, they usually
aren't. But they could be.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Ruben]

On Thu, 17 Jul 2008 03:10:34 +0000, Eugene Vernikovskiy wrote:

*fPointer() = 5; // This makes the expression iX == 5 true;

What akes this snta legal?

Ruben

--
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software

So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998

http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

"Yeah - I write Free Software...so SUE ME"

"The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."

"I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."

© Copyright for the Digital Millennium

[Eugene Vernikovskiy]

Ruben wrote:

On Thu, 17 Jul 2008 03:10:34 +0000, Eugene Vernikovskiy wrote:

>*fPointer() = 5; // This makes the expression iX == 5 true;

What akes this snta legal?

Ruben

Lets reset the example:

1)
int iX = 0;
int* fPointer() { return &iX; }

void f() { *fPointer() = 5; // Puts 5 into iX;
}
If you are surprised that it works this way, why do you think that the
example below works fine:

2)
int iX = 0;
int* pX = &iX;

void f() { *pX = 5; // Puts 5 into iX
}

If you understand that the second example works then reconstruct the
first example as:

3)
int iX = 0;
int* fPointer() { return &iX; }
int* pX = fPointer();

void f() { *pX = 5; // Puts 5 into iX
}

Notice that it is not necessary to assign address returned by the
function into a pointer. It is possible to use this address right away
as in the second example. Each expression which has a type of a pointer
can be dereferenced. For example

int a[10];

*(a+5) = 10; // It is the same as a[5] = 10

Same as

int* p = a; // or &a[0]
*(p+5) = 10; // It is the same as a[5] = 10
Perhaps you misunderstand the meaning of the operation *p. *p is an
l-value which can be used on the left side of the assignment. If *p is
used on the right site of the assignment then it is converter from
l-value to r-value first and then the compiled r-value is used. (I am
not talking about the rules of overloaded operators though, just plain C)

[Eugene Vernikovskiy]

James Kanze wrote:

On Jul 17, 5:10 am, Eugene Vernikovskiy
<[e-mail]:

>I think you can simplify things with references a lot if you
realize that there is no significant difference between
references and pointers.

Oh yes there are. To begin with, references aren't objects, and
pointers are. What you probably meant to say is that references
behave very much like automatically dereferenced pointers.

Yes. My intention was to stress out the similarity between references
and pointers because each C programmer (who knows about pointers) can
start understanding references by assuming that they are automatically
dereferenced pointers.

I do not think that introducing the concept of objects in this
conversation can help understanding the issue. The first step is to
understand similarities and then we can start talking about the
differences :-)

[James Kanze]

On Jul 18, 1:48 am, [e-mail] (Stefan Ram) wrote:

Eugene Vernikovskiy <[e-mail]:

James Kanze wrote:

>Oh yes there are. To begin with, references aren't objects,
and pointers are. What you probably meant to say is that
references behave very much like automatically dereferenced
pointers.

Yes. My intention was to stress out the similarity between
references and pointers because each C programmer (who knows
about pointers) can start understanding references by
assuming that they are automatically dereferenced pointers.

I do not think that introducing the concept of objects in this

FWIW: I didn't really want to disagree too much with Eugene,
because pointing out how pointers and references are similar can
help understanding. But I do think it important to signal from
the start that there are also important differences: references
aren't pointers, even if they behave like pointers in certain
contexts.

I do not agreee with several of the statements above. But
since I do not want to write too much now and already wrote
about references before, I will just choose one example:

James Kanze writes above:

»pointers are objects.«

Usually, pointers are /not/ objects.

A pointer is, by definition, an object, according to the C++
standard. Most importantly, it has the essential
characteristics of an object: it occupies space and has an
address. Neither of which is (necessarily or conceptuallY) true
of a reference.

It is, IMHO, a very important distinction between pointers and
references. You can take the address of a pointer, but not of a
reference. The sizeof operator on a pointer returns the size of
the pointer; the sizeof operator on a reference returns the size
of the referenced object.

In the context the original poster raised, references behave
very much like pointers, as Eugene explained very clearly. In
other contexts, however: a pointer is a first class object in
C++ (more so, even, than an array); a reference isn't an object
at all.

For example:

#include <iostream>
#include <ostream>

int main()
{ char const * const a = "abc";
::std::cout << *( a + 1 ); }

b

(The last line is the output.)

The dereferencing operator »*« requires a pointer operand.

Therefore, »a + 1« is a pointer.
But »a + 1« is not an l-value (you cannot write »( a + 1 )=...«),
so this pointer is not an object. (It /refers/ to an object, but
it is not an object itself.)

What you're saying holds equally well for int or double. »a +
1« is an expression which has pointer type. It's not a pointer
object. On the other hand, anything you declare as a pointer is
an object. There is no such thing as a reference which is an
object.

It is a value (an r-value).

I have heard this misconception that pointers were objects
so often that I wonder how so many people pick up this idea.

It is, I admit, a somewhat careless use of language. There are
really two different ways the word "pointer" (or of »int«, etc.)
are used. One is purely type: an expression has type int, or it
has a pointer type. In the other, we tend to use the work to
mean something declared with that type: i is an int (not "a
variable with type int"), p is a pointer (not "a variable with
pointer type"). From there, it is a simple step to say that
"pointers (ints) are objects", instead of the more precise
"entities declared with pointer type (type int) are objects",
which is, of course, what is really meant. Usually, the context
is such that the actual meaning is clear. (But I'm not sure
that this is the case here, and I should have been clearer.)

Note that even the standard isn't always as clear as one might
like. I think, however, that data types can be divided into
four categories (within expressions, in this regard):

-- the fundamental types, enumeration types, pointers and
pointers to members: objects when they are lvalues, not when
they are rvalues;

-- class types (including unions!): always objects, whether
lvalue or rvalue;

-- arrays: always objects, but can only exist as lvalues (there
are no expressions which result in an rvalue array); and

-- references: never objects.

Using, of course, the definition of object in the C++ standard:
"An object is a region of storage."

Personally, I would rather see fewer categories, with all of the
first three behaving like class types (formally---the lack of
member functions would mean that a compiler could always
"optimize out" the actual object of an rvalue of fundamental
type). Historically, however: we inherit the first and third
points from C, and when you add member functions and a this
pointer, even rvalue class types have to be objects. So we're
stuck with three categories where, were the language defined
from scratch, one would do.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Ruben]

On Thu, 17 Jul 2008 23:02:49 +0000, Eugene Vernikovskiy wrote:

If you are surprised that it works this way, why do you think that the
example below works fine:

YES - I'm astonished. Would this work in C? How is it interpreted?

Ruben

--
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software

So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998

http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

"Yeah - I write Free Software...so SUE ME"

"The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."

"I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."

© Copyright for the Digital Millennium