Thu Oct 28 07:33:28 2021
EVENTS
 FREE
SOFTWARE
INSTITUTE

POLITICS
JOBS
MEMBERS'
CORNER

MAILING
LIST

NYLXS Mailing Lists and Archives
NYLXS Members have a lot to say and share but we don't keep many secrets. Join the Hangout Mailing List and say your peice.

DATE 2008-07-01

HANGOUT

2021-10-28 | 2021-09-28 | 2021-08-28 | 2021-07-28 | 2021-06-28 | 2021-05-28 | 2021-04-28 | 2021-03-28 | 2021-02-28 | 2021-01-28 | 2020-12-28 | 2020-11-28 | 2020-10-28 | 2020-09-28 | 2020-08-28 | 2020-07-28 | 2020-06-28 | 2020-05-28 | 2020-04-28 | 2020-03-28 | 2020-02-28 | 2020-01-28 | 2019-12-28 | 2019-11-28 | 2019-10-28 | 2019-09-28 | 2019-08-28 | 2019-07-28 | 2019-06-28 | 2019-05-28 | 2019-04-28 | 2019-03-28 | 2019-02-28 | 2019-01-28 | 2018-12-28 | 2018-11-28 | 2018-10-28 | 2018-09-28 | 2018-08-28 | 2018-07-28 | 2018-06-28 | 2018-05-28 | 2018-04-28 | 2018-03-28 | 2018-02-28 | 2018-01-28 | 2017-12-28 | 2017-11-28 | 2017-10-28 | 2017-09-28 | 2017-08-28 | 2017-07-28 | 2017-06-28 | 2017-05-28 | 2017-04-28 | 2017-03-28 | 2017-02-28 | 2017-01-28 | 2016-12-28 | 2016-11-28 | 2016-10-28 | 2016-09-28 | 2016-08-28 | 2016-07-28 | 2016-06-28 | 2016-05-28 | 2016-04-28 | 2016-03-28 | 2016-02-28 | 2016-01-28 | 2015-12-28 | 2015-11-28 | 2015-10-28 | 2015-09-28 | 2015-08-28 | 2015-07-28 | 2015-06-28 | 2015-05-28 | 2015-04-28 | 2015-03-28 | 2015-02-28 | 2015-01-28 | 2014-12-28 | 2014-11-28 | 2014-10-28 | 2014-09-28 | 2014-08-28 | 2014-07-28 | 2014-06-28 | 2014-05-28 | 2014-04-28 | 2014-03-28 | 2014-02-28 | 2014-01-28 | 2013-12-28 | 2013-11-28 | 2013-10-28 | 2013-09-28 | 2013-08-28 | 2013-07-28 | 2013-06-28 | 2013-05-28 | 2013-04-28 | 2013-03-28 | 2013-02-28 | 2013-01-28 | 2012-12-28 | 2012-11-28 | 2012-10-28 | 2012-09-28 | 2012-08-28 | 2012-07-28 | 2012-06-28 | 2012-05-28 | 2012-04-28 | 2012-03-28 | 2012-02-28 | 2012-01-28 | 2011-12-28 | 2011-11-28 | 2011-10-28 | 2011-09-28 | 2011-08-28 | 2011-07-28 | 2011-06-28 | 2011-05-28 | 2011-04-28 | 2011-03-28 | 2011-02-28 | 2011-01-28 | 2010-12-28 | 2010-11-28 | 2010-10-28 | 2010-09-28 | 2010-08-28 | 2010-07-28 | 2010-06-28 | 2010-05-28 | 2010-04-28 | 2010-03-28 | 2010-02-28 | 2010-01-28 | 2009-12-28 | 2009-11-28 | 2009-10-28 | 2009-09-28 | 2009-08-28 | 2009-07-28 | 2009-06-28 | 2009-05-28 | 2009-04-28 | 2009-03-28 | 2009-02-28 | 2009-01-28 | 2008-12-28 | 2008-11-28 | 2008-10-28 | 2008-09-28 | 2008-08-28 | 2008-07-28 | 2008-06-28 | 2008-05-28 | 2008-04-28 | 2008-03-28 | 2008-02-28 | 2008-01-28 | 2007-12-28 | 2007-11-28 | 2007-10-28 | 2007-09-28 | 2007-08-28 | 2007-07-28 | 2007-06-28 | 2007-05-28 | 2007-04-28 | 2007-03-28 | 2007-02-28 | 2007-01-28 | 2006-12-28 | 2006-11-28 | 2006-10-28 | 2006-09-28 | 2006-08-28 | 2006-07-28 | 2006-06-28 | 2006-05-28 | 2006-04-28 | 2006-03-28 | 2006-02-28 | 2006-01-28 | 2005-12-28 | 2005-11-28 | 2005-10-28 | 2005-09-28 | 2005-08-28 | 2005-07-28 | 2005-06-28 | 2005-05-28 | 2005-04-28 | 2005-03-28 | 2005-02-28 | 2005-01-28 | 2004-12-28 | 2004-11-28 | 2004-10-28 | 2004-09-28 | 2004-08-28 | 2004-07-28 | 2004-06-28 | 2004-05-28 | 2004-04-28 | 2004-03-28 | 2004-02-28 | 2004-01-28 | 2003-12-28 | 2003-11-28 | 2003-10-28 | 2003-09-28 | 2003-08-28 | 2003-07-28 | 2003-06-28 | 2003-05-28 | 2003-04-28 | 2003-03-28 | 2003-02-28 | 2003-01-28 | 2002-12-28 | 2002-11-28 | 2002-10-28 | 2002-09-28 | 2002-08-28 | 2002-07-28 | 2002-06-28 | 2002-05-28 | 2002-04-28 | 2002-03-28 | 2002-02-28 | 2002-01-28 | 2001-12-28 | 2001-11-28 | 2001-10-28 | 2001-09-28 | 2001-08-28 | 2001-07-28 | 2001-06-28 | 2001-05-28 | 2001-04-28 | 2001-03-28 | 2001-02-28 | 2001-01-28 | 2000-12-28 | 2000-11-28 | 2000-10-28 | 2000-09-28 | 2000-08-28 | 2000-07-28 | 2000-06-28 | 2000-05-28 | 2000-04-28 | 2000-03-28 | 2000-02-28 | 2000-01-28 | 1999-12-28

Key: Value:

Key: Value:

MESSAGE
DATE 2008-07-15
FROM Ruben Safir
SUBJECT Subject: [NYLXS - HANGOUT] C++ Workshop 2.2
From lest-hangout-at-mrbrklyn.com Tue Jul 15 23:32:25 2008
Received: from www2.mrbrklyn.com (localhost [127.0.0.1])
by www2.mrbrklyn.com (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id m6G3WNan020208
for ; Tue, 15 Jul 2008 23:32:25 -0400
Received: (from majordomo-at-localhost)
by www2.mrbrklyn.com (8.13.1/8.13.1/Submit) id m6G3WMJP020207
for hangout-outgoings; Tue, 15 Jul 2008 23:32:22 -0400
X-Authentication-Warning: www2.mrbrklyn.com: majordomo set sender to lest-hangout-at-nylxs.com using -f
Received: from www2.mrbrklyn.com (localhost [127.0.0.1])
by www2.mrbrklyn.com (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id m6G3WJHS020201;
Tue, 15 Jul 2008 23:32:21 -0400
Received: (from ruben-at-localhost)
by www2.mrbrklyn.com (8.13.1/8.13.1/Submit) id m6G3WJIQ020200;
Tue, 15 Jul 2008 23:32:19 -0400
Date: Tue, 15 Jul 2008 23:32:19 -0400
From: Ruben Safir
To: hangout-at-mrbrklyn.com
Subject: [NYLXS - HANGOUT] C++ Workshop 2.2
Message-ID: <20080716033219.GA20163-at-www2.mrbrklyn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.6i
Sender: lest-hangout-at-mrbrklyn.com
Precedence: bulk
Reply-To: hangout-at-mrbrklyn.com

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

  1. 2008-07-01 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] C programming Workshop part II
  2. 2008-07-01 swd <sderrick-at-optonline.net> Re: [NYLXS - HANGOUT] Need to get rid of a whole bunch of programming
  3. 2008-07-01 email <ray-pub-at-rcn.com> Re: [NYLXS - HANGOUT] Need to get rid of a whole bunch of programming
  4. 2008-07-01 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] Need to get rid of a whole bunch of programming books. TALK ABOUT FREE SOFTWARE!!!
  5. 2008-07-01 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] Gates: Windows really sucks
  6. 2008-07-01 email <ray-pub-at-rcn.com> Re: [NYLXS - HANGOUT] Need to get rid of a whole bunch of programming
  7. 2008-07-02 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] [david-at-thekramers.net: Fedora 9 X dual screen problems]
  8. 2008-07-02 swd <sderrick-at-optonline.net> Re: [NYLXS - HANGOUT] Need to get rid of a whole bunch of programming
  9. 2008-07-02 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] C++ Workshop 2 (section 2.1)
  10. 2008-07-03 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] C++ Workshop 2.1
  11. 2008-07-03 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] July 4th
  12. 2008-07-03 Shoshana Rivka Safir <shani-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] Post high school jobs or internships?
  13. 2008-07-03 meg7-at-nyu.edu Re: [NYLXS - HANGOUT] July 4th
  14. 2008-07-03 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] July 4th
  15. 2008-07-03 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] July 4th
  16. 2008-07-03 From: "Ronny Abraham" <ronny.coder-at-gmail.com> Re: [NYLXS - HANGOUT] Post high school jobs or internships?
  17. 2008-07-03 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] C++ Workshop 2.3
  18. 2008-07-03 From: "Michael L. Richardson" <mlr52-at-michaellrichardson.com> Re: [NYLXS - HANGOUT] Post high school jobs or internships?
  19. 2008-07-04 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] [alan-at-patriot.net: [Dclug] Our Fourth Amendment]
  20. 2008-07-04 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] 4th of July Plans
  21. 2008-07-04 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] Workshops
  22. 2008-07-05 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] Might be time for a visit to Congress again
  23. 2008-07-05 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  24. 2008-07-05 From: "Michael L. Richardson" <mlr52-at-mycouponmagic.com> Re: [NYLXS - HANGOUT] Workshops
  25. 2008-07-05 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] Workshops
  26. 2008-07-06 From: "Ronny Abraham" <ronny.coder-at-gmail.com> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  27. 2008-07-07 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] [meissner-at-suse.de: [security-announce] SUSE Security Announcement: Linux kernel (SUSE-SA:2008:031)]
  28. 2008-07-07 Mark Simko <msimko-at-optonline.net> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  29. 2008-07-07 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] [meissner-at-suse.de: [security-announce] SUSE Security Announcement: Linux kernel (SUSE-SA:2008:032)]
  30. 2008-07-07 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  31. 2008-07-07 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  32. 2008-07-07 Mark Simko <msimko-at-optonline.net> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  33. 2008-07-07 Mark Simko <msimko-at-optonline.net> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  34. 2008-07-07 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  35. 2008-07-07 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  36. 2008-07-07 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  37. 2008-07-07 Mark Simko <msimko-at-optonline.net> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  38. 2008-07-07 Mark Simko <msimko-at-optonline.net> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  39. 2008-07-07 From: "Ronny Abraham" <ronny.coder-at-gmail.com> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  40. 2008-07-07 Ron Guerin <ron-at-vnetworx.net> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  41. 2008-07-07 From: "Ronny Abraham" <ronny.coder-at-gmail.com> Re: [NYLXS - HANGOUT] Post high school jobs or internships?
  42. 2008-07-07 From: "Ronny Abraham" <ronny.coder-at-gmail.com> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  43. 2008-07-07 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] [nyc-at-workatjelly.com: Jelly in Manhattan this Friday, 7/11]
  44. 2008-07-07 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  45. 2008-07-07 Ron Guerin <ron-at-vnetworx.net> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  46. 2008-07-07 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  47. 2008-07-07 From: "Ronny Abraham" <ronny.coder-at-gmail.com> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  48. 2008-07-08 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  49. 2008-07-08 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  50. 2008-07-08 Mark Simko <msimko-at-optonline.net> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  51. 2008-07-08 From: "Ronny Abraham" <ronny.coder-at-gmail.com> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  52. 2008-07-08 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  53. 2008-07-08 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  54. 2008-07-08 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  55. 2008-07-08 From: "Ronny Abraham" <ronny.coder-at-gmail.com> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  56. 2008-07-08 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] Maybe its because lindows just sucked
  57. 2008-07-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] ASUS/GNU
  58. 2008-07-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] While we're on this topic
  59. 2008-07-08 From: "Tameek" <tameek-at-gmail.com> Re: [NYLXS - HANGOUT] [nyc-at-workatjelly.com: Jelly in Manhattan this Friday, 7/11]
  60. 2008-07-08 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] [nyc-at-workatjelly.com: Jelly in Manhattan this Friday, 7/11]
  61. 2008-07-09 email <ray-pub-at-rcn.com> Re: [NYLXS - HANGOUT] [nyc-at-workatjelly.com: Jelly in Manhattan this
  62. 2008-07-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] Installfest this weekend?
  63. 2008-07-09 email <ray-pub-at-rcn.com> Re: [NYLXS - HANGOUT] Installfest this weekend?
  64. 2008-07-09 Mark Simko <msimko-at-optonline.net> Re: [NYLXS - HANGOUT] Post high school jobs or internships?
  65. 2008-07-12 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] Installfest this weekend?
  66. 2008-07-12 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] GNU/Linux INSTALLFEST/HACKFEST NYC Local
  67. 2008-07-12 Contrarian <adrba-at-nyct.net> Subject: [NYLXS - HANGOUT] "Gates of Vienna" blog averts DMCA prosecution
  68. 2008-07-14 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] Re: Linux on the desktop - it's come a long way, but is it there yet?
  69. 2008-07-15 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] so much for Apples Free Software pitch
  70. 2008-07-15 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] grep
  71. 2008-07-15 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] grep
  72. 2008-07-15 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] C++ Workshop 2.2
  73. 2008-07-18 Contrarian <adrba-at-nyct.net> Subject: [NYLXS - HANGOUT] [BrooklynFreeCycle] offer---- old library card catalog file cabinet
  74. 2008-07-18 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] HAckfest/Installfest
  75. 2008-07-18 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] Re: [nylug-talk] HAckfest/Installfest
  76. 2008-07-18 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] Hackfest/Installfest
  77. 2008-07-18 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] Tax Exempy Status
  78. 2008-07-19 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] Installfest/Hackfest Tomorrow
  79. 2008-07-20 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] Installfest/Hackfest
  80. 2008-07-21 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] [notification+zjaayj4y-at-facebookmail.com: "Ted & Amy Supper Club (NYC)" sent you a message on Facebook...]
  81. 2008-07-22 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] C++ Workshop 2.2.3
  82. 2008-07-22 From: "Ronny Abraham" <ronny.coder-at-gmail.com> Re: [NYLXS - HANGOUT] [notification+zjaayj4y-at-facebookmail.com: "Ted & Amy Supper Club (NYC)" sent you a message on Facebook...]
  83. 2008-07-22 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] [notification+zjaayj4y-at-facebookmail.com: "Ted & Amy Supper Club (NYC)" sent you a message on Facebook...]
  84. 2008-07-23 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] C Programming Workshop
  85. 2008-07-23 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] [dalmolin-at-e-cology.ca: [Hardhats] COMMITTEE ON WAYS AND MEANS: Promoting Health IT Hearing]
  86. 2008-07-23 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] C++ Workshop 2.3.4
  87. 2008-07-24 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] Dell GNU Systems
  88. 2008-07-25 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] [rick-at-linuxmafia.com: [conspire] DNS vulnerability details]
  89. 2008-07-25 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] Re: [conspire] DNS vulnerability details
  90. 2008-07-25 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] Re: [conspire] DNS vulnerability details
  91. 2008-07-25 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] Radio Broadcasting
  92. 2008-07-25 prmarino1-at-gmail.com Re: [NYLXS - HANGOUT] [rick-at-linuxmafia.com: [conspire] DNS vulnerability details]
  93. 2008-07-25 prmarino1-at-gmail.com Re: [NYLXS - HANGOUT] [rick-at-linuxmafia.com: [conspire] DNS vulnerability details]
  94. 2008-07-25 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] Re: [conspire] DNS vulnerability details
  95. 2008-07-26 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] unionfs
  96. 2008-07-26 Mark Simko <msimko-at-optonline.net> Re: [NYLXS - HANGOUT] unionfs
  97. 2008-07-26 From: "Michael L. Richardson" <mlr52-at-michaellrichardson.com> Re: [NYLXS - HANGOUT] unionfs
  98. 2008-07-27 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] unionfs
  99. 2008-07-27 Mark Simko <msimko-at-optonline.net> Re: [NYLXS - HANGOUT] unionfs
  100. 2008-07-27 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] unionfs
  101. 2008-07-27 Mark Simko <msimko-at-optonline.net> Re: [NYLXS - HANGOUT] unionfs
  102. 2008-07-27 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] unionfs
  103. 2008-07-28 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] [nyc-at-workatjelly.com: Jelly in Fort Greene Friday, 8/1]
  104. 2008-07-29 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] [Volunteer4-at-JohnMcCain.com: McCain Campaign Internships]
  105. 2008-07-30 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] August Plans
  106. 2008-07-30 From: <tameek-at-gmail.com> RE: [NYLXS - HANGOUT] August Plans
  107. 2008-07-30 From: "Michael L. Richardson" <mlr52-at-michaellrichardson.com> Re: [NYLXS - HANGOUT] August Plans
  108. 2008-07-30 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] August Plans
  109. 2008-07-30 email <ray-pub-at-rcn.com> Re: [NYLXS - HANGOUT] August Plans
  110. 2008-07-30 From: <tameek-at-gmail.com> RE: [NYLXS - HANGOUT] August Plans
  111. 2008-07-30 From: "Michael L. Richardson" <mlr52-at-mycouponmagic.com> Re: [NYLXS - HANGOUT] August Plans
  112. 2008-07-30 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] August Plans
  113. 2008-07-30 From: "Michael L. Richardson" <mlr52-at-michaellrichardson.com> Re: [NYLXS - HANGOUT] August Plans
  114. 2008-07-30 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] August Plans
  115. 2008-07-30 From: <mlr52-at-michaellrichardson.com> Re: [NYLXS - HANGOUT] August Plans
  116. 2008-07-31 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] Time to trash the eeepc
  117. 2008-07-31 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [NYLXS - HANGOUT] KDE really sucks
  118. 2008-07-31 email <ray-pub-at-rcn.com> Re: [NYLXS - HANGOUT] KDE really sucks
  119. 2008-07-31 prmarino1-at-gmail.com Re: [NYLXS - HANGOUT] Time to trash the eeepc
  120. 2008-07-31 prmarino1-at-gmail.com Re: [NYLXS - HANGOUT] Time to trash the eeepc
  121. 2008-07-31 prmarino1-at-gmail.com Re: [NYLXS - HANGOUT] KDE really sucks
  122. 2008-07-31 prmarino1-at-gmail.com Re: [NYLXS - HANGOUT] KDE really sucks
  123. 2008-07-31 From: "Stan Davenport" <stan-at-Etrtechcenter.com> Subject: [NYLXS - HANGOUT] Ruben,Opening On Long Island Near Hicksville RR Linix Developer Any
  124. 2008-07-31 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] KDE really sucks
  125. 2008-07-31 Mark Simko <msimko-at-optonline.net> Re: [NYLXS - HANGOUT] Time to trash the eeepc
  126. 2008-07-31 prmarino1-at-gmail.com Re: [NYLXS - HANGOUT] Time to trash the eeepc
  127. 2008-07-31 prmarino1-at-gmail.com Re: [NYLXS - HANGOUT] Time to trash the eeepc
  128. 2008-07-31 Ruben Safir <ruben-at-mrbrklyn.com> Re: [NYLXS - HANGOUT] Time to trash the eeepc
  129. 2008-07-31 From: <mlr52-at-michaellrichardson.com> Re: [NYLXS - HANGOUT] Time to trash the eeepc
  130. 2008-07-31 prmarino1-at-gmail.com Re: [NYLXS - HANGOUT] Time to trash the eeepc
  131. 2008-07-31 prmarino1-at-gmail.com Re: [NYLXS - HANGOUT] Time to trash the eeepc
  132. 2008-07-31 prmarino1-at-gmail.com Re: [NYLXS - HANGOUT] Time to trash the eeepc
  133. 2008-07-31 prmarino1-at-gmail.com Re: [NYLXS - HANGOUT] Time to trash the eeepc
  134. 2008-07-31 From: <mlr52-at-michaellrichardson.com> Re: [NYLXS - HANGOUT] Time to trash the eeepc

NYLXS are Do'ers and the first step of Doing is Joining! Join NYLXS and make a difference in your community today!