MESSAGE
| DATE | 2008-07-15 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [NYLXS - HANGOUT] C++ Workshop 2.2
|
OK - I'll try this again
I've been working on the C++ Workshop, but didn't post because I hit a bump in the
road with understanding some code involving references and because I've been working
on building a real life example and needed some more insight on program structure than
I've been able to gleen from the texts.
I have been discussing the issues in detail, however, on usenet and I'm posting
that conversation for your benifit here, just to keep you in the know
Date: Mon, 14 Jul 2008 06:06:32 -0400
From: Ruben
Lines: 28
Message-ID:
NNTP-Posting-Date: Mon, 14 Jul 2008 10:06:13 +0000 (UTC)
NNTP-Posting-Host: www.mrbrklyn.com
Newsgroups: comp.lang.c++
Organization: NYLXS
Path: reader1.panix.com!panix!not-for-mail
Subject: reference type methods
User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.)
X-Complaints-To: abuse-at-panix.com
X-DRMisTHEFT: Use GNU Linux today
X-LOCATION: Brooklyn NY - Forget abou' it!
X-NYLXS: Really - yah think computers are supposed to be broken?
X-Trace: reader1.panix.com 1216029973 17480 68.167.17.98 (14 Jul 2008 10:06:13 GMT)
Xref: panix comp.lang.c++:1015695
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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
_____________________________________________________________________________
Cancel-Lock: sha1:IcvhHgj6+zUiRDDT9sDYyjGZO5k=
Date: Mon, 14 Jul 2008 22:11:19 +1200
From: Ian Collins
In-Reply-To:
Lines: 15
Message-ID: <6e0n27F4ljr3U3-at-mid.individual.net>
Newsgroups: comp.lang.c++
Path: reader1.panix.com!panix!newsfeed-00.mathworks.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
References:
Subject: Re: reference type methods
User-Agent: Thunderbird 2.0.0.14 (X11/20080519)
X-Trace: individual.net aYKTVJKnklkSqmxVnQ6Y8gYkwoPbm7s6r6kaW9ljyYnpFvIF9c
Xref: panix comp.lang.c++:1015697
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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.
_____________________________________________________________________________________
Date: Mon, 14 Jul 2008 06:20:07 -0400
From: Ruben
Lines: 43
Message-ID:
NNTP-Posting-Date: Mon, 14 Jul 2008 10:19:48 +0000 (UTC)
NNTP-Posting-Host: www.mrbrklyn.com
Newsgroups: comp.lang.c++
Organization: NYLXS
Path: reader1.panix.com!panix!not-for-mail
References: <6e0n27F4ljr3U3-at-mid.individual.net>
Subject: Re: reference type methods
User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.)
X-Complaints-To: abuse-at-panix.com
X-DRMisTHEFT: Use GNU Linux today
X-LOCATION: Brooklyn NY - Forget abou' it!
X-NYLXS: Really - yah think computers are supposed to be broken?
X-Trace: reader1.panix.com 1216030788 19414 68.167.17.98 (14 Jul 2008 10:19:48 GMT)
Xref: panix comp.lang.c++:1015701
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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
___________________________________________________________________________________
ancel-Lock: sha1:niAoDn/GOH9EhEluhR8PKpgeUeA=
Date: Mon, 14 Jul 2008 22:30:24 +1200
From: Ian Collins
In-Reply-To:
Lines: 29
Message-ID: <6e0o60F4ljr3U6-at-mid.individual.net>
Newsgroups: comp.lang.c++
Path: reader1.panix.com!panix!newsfeed-00.mathworks.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
References: <6e0n27F4ljr3U3-at-mid.individual.net>
Subject: Re: reference type methods
User-Agent: Thunderbird 2.0.0.14 (X11/20080519)
X-Trace: individual.net Hlgt/RSN7wYOL3ldfSr1iQr4h7EuC6Bw+jmZ7HHw8dvPGio0Om
Xref: panix comp.lang.c++:1015703
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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.
____________________________________________________________________
Date: Mon, 14 Jul 2008 07:05:02 -0400
From: Ruben
Lines: 56
Message-ID:
NNTP-Posting-Date: Mon, 14 Jul 2008 11:04:43 +0000 (UTC)
NNTP-Posting-Host: www.mrbrklyn.com
Newsgroups: comp.lang.c++
Organization: NYLXS
Path: reader1.panix.com!panix!not-for-mail
References: <6e0n27F4ljr3U3-at-mid.individual.net> <6e0o60F4ljr3U6-at-mid.individual.net>
Subject: Re: reference type methods
User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.)
X-Complaints-To: abuse-at-panix.com
X-DRMisTHEFT: Use GNU Linux today
X-LOCATION: Brooklyn NY - Forget abou' it!
X-NYLXS: Really - yah think computers are supposed to be broken?
X-Trace: reader1.panix.com 1216033483 25596 68.167.17.98 (14 Jul 2008 11:04:43 GMT)
Xref: panix comp.lang.c++:1015708
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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
_____________________________________________________________________________
Cancel-Lock: sha1:oHBwceQLSNGnfKxKtBZaDDcRBz0=
Date: Mon, 14 Jul 2008 23:26:07 +1200
From: Ian Collins
In-Reply-To:
Lines: 21
Message-ID: <6e0refF4ja02U2-at-mid.individual.net>
Newsgroups: comp.lang.c++
Path: reader1.panix.com!panix!newsfeed-00.mathworks.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
References: <6e0n27F4ljr3U3-at-mid.individual.net> <6e0o60F4ljr3U6-at-mid.individual.net>
Subject: Re: reference type methods
User-Agent: Thunderbird 2.0.0.14 (X11/20080519)
X-Trace: individual.net g4GZDFipqaWGvlSKH4odmANstzYWlbc8PXXV34/JTYrBzgGFOe
Xref: panix comp.lang.c++:1015710
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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.
______________________________________________________________________________________________
Date: Mon, 14 Jul 2008 07:31:45 -0400
From: Ruben
Lines: 45
Message-ID:
NNTP-Posting-Date: Mon, 14 Jul 2008 11:31:26 +0000 (UTC)
NNTP-Posting-Host: www.mrbrklyn.com
Newsgroups: comp.lang.c++
Organization: NYLXS
Path: reader1.panix.com!panix!not-for-mail
References: <6e0n27F4ljr3U3-at-mid.individual.net> <6e0o60F4ljr3U6-at-mid.individual.net> <6e0refF4ja02U2-at-mid.individual.net>
Subject: Re: reference type methods
User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.)
X-Complaints-To: abuse-at-panix.com
X-DRMisTHEFT: Use GNU Linux today
X-LOCATION: Brooklyn NY - Forget abou' it!
X-NYLXS: Really - yah think computers are supposed to be broken?
X-Trace: reader1.panix.com 1216035086 15387 68.167.17.98 (14 Jul 2008 11:31:26 GMT)
Xref: panix comp.lang.c++:1015713
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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
-----------------------------------------------------------------------
ancel-Lock: sha1:/y8EQdX57yVmtPTUgxdCiFSGYKY=
Date: Mon, 14 Jul 2008 23:36:45 +1200
From: Ian Collins
In-Reply-To:
Lines: 41
Message-ID: <6e0s2dF4ja02U3-at-mid.individual.net>
Newsgroups: comp.lang.c++
Path: reader1.panix.com!panix!newsfeed-00.mathworks.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
References: <6e0n27F4ljr3U3-at-mid.individual.net> <6e0o60F4ljr3U6-at-mid.individual.net> <6e0refF4ja02U2-at-mid.individual.net>
Subject: Re: reference type methods
User-Agent: Thunderbird 2.0.0.14 (X11/20080519)
X-Trace: individual.net ewKA3n2fbihye6+c6XM8egcWiw3xPfhyuY+MJlbY/l5kszil0g
Xref: panix comp.lang.c++:1015715
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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.
---------------------------------------------------------------------------------
Date: Mon, 14 Jul 2008 20:24:22 -0400
From: Ruben
Lines: 62
Message-ID:
NNTP-Posting-Date: Tue, 15 Jul 2008 00:24:04 +0000 (UTC)
NNTP-Posting-Host: www.mrbrklyn.com
Newsgroups: comp.lang.c++
Organization: NYLXS
Path: reader1.panix.com!panix!not-for-mail
References: <6e0n27F4ljr3U3-at-mid.individual.net> <6e0o60F4ljr3U6-at-mid.individual.net> <6e0refF4ja02U2-at-mid.individual.net> <6e0s2dF4ja02U3-at-mid.individual.net>
Subject: Re: reference type methods
User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.)
X-Complaints-To: abuse-at-panix.com
X-DRMisTHEFT: Use GNU Linux today
X-LOCATION: Brooklyn NY - Forget abou' it!
X-NYLXS: Really - yah think computers are supposed to be broken?
X-Trace: reader1.panix.com 1216081444 18071 68.167.17.98 (15 Jul 2008 00:24:04 GMT)
Xref: panix comp.lang.c++:1015769
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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
----------------------------------------------------------------------
Date: Mon, 14 Jul 2008 23:12:35 -0400
From: Ruben
Lines: 88
Message-ID:
NNTP-Posting-Date: Tue, 15 Jul 2008 03:12:16 +0000 (UTC)
NNTP-Posting-Host: www.mrbrklyn.com
Newsgroups: comp.lang.c++
Organization: NYLXS
Path: reader1.panix.com!panix!not-for-mail
References: <6e0n27F4ljr3U3-at-mid.individual.net> <6e0o60F4ljr3U6-at-mid.individual.net> <6e0refF4ja02U2-at-mid.individual.net> <6e0s2dF4ja02U3-at-mid.individual.net>
Subject: Re: reference type methods
User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.)
X-Complaints-To: abuse-at-panix.com
X-DRMisTHEFT: Use GNU Linux today
X-LOCATION: Brooklyn NY - Forget abou' it!
X-NYLXS: Really - yah think computers are supposed to be broken?
X-Trace: reader1.panix.com 1216091536 13410 68.167.17.98 (15 Jul 2008 03:12:16 GMT)
Xref: panix comp.lang.c++:1015776
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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
----------------------------------------------------------------------------------------
Date: Tue, 15 Jul 2008 08:21:48 +0000 (UTC)
From: Lionel B
Lines: 50
Message-ID:
NNTP-Posting-Date: Tue, 15 Jul 2008 08:21:48 +0000 (UTC)
NNTP-Posting-Host: bordeaux.rn.informatics.scitech.susx.ac.uk
Newsgroups: comp.lang.c++
Organization: Janet Usenet Reading Service.
Path: reader1.panix.com!panix!bloom-beacon.mit.edu!npeer.de.kpn-eurorings.net!npeer-ng2.kpn.DE!newsfeeder.dynfx.net!weretis.net!dedekind.zen.co.uk!zen.net.uk!hamilton.zen.co.uk!feed4.jnfs.ja.net!jnfs.ja.net!south.jnrs.ja.net!not-for-mail
References: <6e0n27F4ljr3U3-at-mid.individual.net> <6e0o60F4ljr3U6-at-mid.individual.net> <6e0refF4ja02U2-at-mid.individual.net> <6e0s2dF4ja02U3-at-mid.individual.net>
Subject: Re: reference type methods
User-Agent: Pan/0.132 (Waxed in Black)
X-Complaints-To: usenet-at-south.jnrs.ja.net
X-Trace: south.jnrs.ja.net 1216110108 5043 139.184.48.176 (15 Jul 2008 08:21:48 GMT)
Xref: panix comp.lang.c++:1015792
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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
______________________________________________________________________________________
Cancel-Lock: sha1:eyCscxoeiZxyOoTXtgN/Viv/+jY=
Date: Tue, 15 Jul 2008 20:38:44 +1200
From: Ian Collins
In-Reply-To:
Lines: 42
Message-ID: <6e360kF523j1U2-at-mid.individual.net>
Newsgroups: comp.lang.c++
Path: reader1.panix.com!panix!newsfeed-00.mathworks.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
References: <6e0n27F4ljr3U3-at-mid.individual.net> <6e0o60F4ljr3U6-at-mid.individual.net> <6e0refF4ja02U2-at-mid.individual.net> <6e0s2dF4ja02U3-at-mid.individual.net>
Subject: Re: reference type methods
User-Agent: Thunderbird 2.0.0.14 (X11/20080519)
X-Trace: individual.net 4vyswjGGm4Q0V3SdeSNEcgiCy+SfJB1GEeGgzbaa5bGjjkWzpj
Xref: panix comp.lang.c++:1015797
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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.
------------------------------------------------------------------------------
Complaints-To: groups-abuse-at-google.com
Date: Tue, 15 Jul 2008 02:32:48 -0700 (PDT)
From: James Kanze
Injection-Info: j22g2000hsf.googlegroups.com; posting-host=62.160.54.162; posting-account=1W_PtwoAAAA1QoMcl2Z5P6j-DNc8HR3W
Lines: 102
Message-ID: <32054362-f427-4a50-aad3-fdc9e4f38c5c-at-j22g2000hsf.googlegroups.com>
NNTP-Posting-Date: Tue, 15 Jul 2008 09:33:16 +0000 (UTC)
NNTP-Posting-Host: 62.160.54.162
Newsgroups: comp.lang.c++
Organization: http://groups.google.com
Path: reader1.panix.com!panix!newsfeed.stanford.edu!postnews.google.com!j22g2000hsf.googlegroups.com!not-for-mail
References: <6e0n27F4ljr3U3-at-mid.individual.net> <6e0o60F4ljr3U6-at-mid.individual.net> <6e0refF4ja02U2-at-mid.individual.net> <6e0s2dF4ja02U3-at-mid.individual.net>
Subject: Re: reference type methods
User-Agent: G2/1.0
X-Complaints-To: groups-abuse-at-google.com
X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.15) Gecko/20080623 Firefox/2.0.0.15,gzip(gfe),gzip(gfe)
X-HTTP-Via: 1.1 paisc001:8181 (IWSS)
X-Trace: posting.google.com 1216114396 26528 127.0.0.1 (15 Jul 2008 09:33:16 GMT)
Xref: panix comp.lang.c++:1015805
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Jul 15, 5:12 am, Ruben wrote:
> 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:james.kanze-at-gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
--------------------------------------------------------------------------------
Date: Tue, 15 Jul 2008 07:37:45 -0400
From: Ruben
Lines: 55
Message-ID:
NNTP-Posting-Date: Tue, 15 Jul 2008 11:37:26 +0000 (UTC)
NNTP-Posting-Host: www.mrbrklyn.com
Newsgroups: comp.lang.c++
Organization: NYLXS
Path: reader1.panix.com!panix!not-for-mail
References: <6e0n27F4ljr3U3-at-mid.individual.net> <6e0o60F4ljr3U6-at-mid.individual.net> <6e0refF4ja02U2-at-mid.individual.net> <6e0s2dF4ja02U3-at-mid.individual.net> <32054362-f427-4a50-aad3-fdc9e4f38c5c-at-j22g2000hsf.googlegroups.com>
Subject: Re: reference type methods
User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.)
X-Complaints-To: abuse-at-panix.com
X-DRMisTHEFT: Use GNU Linux today
X-LOCATION: Brooklyn NY - Forget abou' it!
X-NYLXS: Really - yah think computers are supposed to be broken?
X-Trace: reader1.panix.com 1216121846 24690 68.167.17.98 (15 Jul 2008 11:37:26 GMT)
Xref: panix comp.lang.c++:1015819
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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
-------------------------------------------------------------------------------
Date: Tue, 15 Jul 2008 07:43:59 -0400
From: Ruben
Lines: 68
Message-ID:
NNTP-Posting-Date: Tue, 15 Jul 2008 11:43:40 +0000 (UTC)
NNTP-Posting-Host: www.mrbrklyn.com
Newsgroups: comp.lang.c++
Organization: NYLXS
Path: reader1.panix.com!panix!not-for-mail
References: <6e0n27F4ljr3U3-at-mid.individual.net> <6e0o60F4ljr3U6-at-mid.individual.net> <6e0refF4ja02U2-at-mid.individual.net> <6e0s2dF4ja02U3-at-mid.individual.net> <6e360kF523j1U2-at-mid.individual.net>
Subject: Re: reference type methods
User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.)
X-Complaints-To: abuse-at-panix.com
X-DRMisTHEFT: Use GNU Linux today
X-LOCATION: Brooklyn NY - Forget abou' it!
X-NYLXS: Really - yah think computers are supposed to be broken?
X-Trace: reader1.panix.com 1216122220 15732 68.167.17.98 (15 Jul 2008 11:43:40 GMT)
Xref: panix comp.lang.c++:1015820
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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.
--------------------------------------------------------------------------------
Complaints-To: groups-abuse-at-google.com
Date: Tue, 15 Jul 2008 06:04:43 -0700 (PDT)
From: James Kanze
Injection-Info: 79g2000hsk.googlegroups.com; posting-host=62.160.54.162; posting-account=1W_PtwoAAAA1QoMcl2Z5P6j-DNc8HR3W
Lines: 65
Message-ID:
NNTP-Posting-Date: Tue, 15 Jul 2008 13:04:44 +0000 (UTC)
NNTP-Posting-Host: 62.160.54.162
Newsgroups: comp.lang.c++
Organization: http://groups.google.com
Path: reader1.panix.com!panix!newsfeed.stanford.edu!postnews.google.com!79g2000hsk.googlegroups.com!not-for-mail
References: <6e0n27F4ljr3U3-at-mid.individual.net> <6e0o60F4ljr3U6-at-mid.individual.net> <6e0refF4ja02U2-at-mid.individual.net> <6e0s2dF4ja02U3-at-mid.individual.net> <32054362-f427-4a50-aad3-fdc9e4f38c5c-at-j22g2000hsf.googlegroups.com>
Subject: Re: reference type methods
User-Agent: G2/1.0
X-Complaints-To: groups-abuse-at-google.com
X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.15) Gecko/20080623 Firefox/2.0.0.15,gzip(gfe),gzip(gfe)
X-HTTP-Via: 1.1 paisc001:8181 (IWSS)
X-Trace: posting.google.com 1216127084 15115 127.0.0.1 (15 Jul 2008 13:04:44 GMT)
Xref: panix comp.lang.c++:1015825
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Jul 15, 1:37 pm, Ruben wrote:
> 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:james.kanze-at-gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
______________________________________________________________________________
Date: Tue, 15 Jul 2008 18:43:49 -0400
From: Ruben
Lines: 74
Message-ID:
NNTP-Posting-Date: Tue, 15 Jul 2008 22:43:30 +0000 (UTC)
NNTP-Posting-Host: www.mrbrklyn.com
Newsgroups: comp.lang.c++
Organization: NYLXS
Path: reader1.panix.com!panix!not-for-mail
References: <6e0n27F4ljr3U3-at-mid.individual.net> <6e0o60F4ljr3U6-at-mid.individual.net> <6e0refF4ja02U2-at-mid.individual.net> <6e0s2dF4ja02U3-at-mid.individual.net> <32054362-f427-4a50-aad3-fdc9e4f38c5c-at-j22g2000hsf.googlegroups.com>
Subject: Re: reference type methods
User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.)
X-Complaints-To: abuse-at-panix.com
X-DRMisTHEFT: Use GNU Linux today
X-LOCATION: Brooklyn NY - Forget abou' it!
X-NYLXS: Really - yah think computers are supposed to be broken?
X-Trace: reader1.panix.com 1216161810 2089 68.167.17.98 (15 Jul 2008 22:43:30 GMT)
Xref: panix comp.lang.c++:1015897
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
On Tue, 15 Jul 2008 06:04:43 -0700, James Kanze wrote:
>> 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.
Ah - yes.
That's where I started. This is a definition as I see it, not an implied
affect of references. My text makes it seem like if a function is defined
to return a reference then
simply .....
class f;
class f(int x){
public:
f(){
_x = 10;
}
}
int& g(int x){
_x = x;
return _x;
}
}
private:
int _x;
};
f him, her;
her.g(5);
him.g = her.g;
...BECAUSE him.g is an lvalue of type 'refence', as if the order of
operations of the statement would evaluate the left side of the method g
as returning a reference, which would stand in the functions place which
is an lvalue.
It might be an lvalue but if not for some C++ magic syntax behavior, i'd
first expect a type missmatch, as I would if the return type of g() was a
char, or a pointer to array, and then I returned an int. Secondly, I
wouldn't expect the assignment operator to work anyway!
In the case of a the operator[], I thought I might need another operator
overload function called operator[]=
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
|
|
