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]

Re: reference type methods

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]

Re: reference type methods

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]

Re: reference type methods

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]

Re: reference type methods

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]

Re: reference type methods

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]

Re: reference type methods

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]

Re: reference type methods

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]

Re: reference type methods

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]

Re: reference type methods

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...act ually 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]

Re: reference type methods

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 "alternativ e 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]

Re: reference type methods

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]

Re: reference type methods

On Jul 15, 5:12 am, Ruben <ru...@www2.mrb rklyn.comwrote:

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...act ually 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:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[Ruben]

Re: reference type methods

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]

Re: reference type methods

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