Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #6809 > unrolled thread
| Started by | jacob navia <jacob@spamsink.net> |
|---|---|
| First post | 2011-06-24 10:42 +0200 |
| Last post | 2011-07-04 17:43 -0400 |
| Articles | 20 on this page of 135 — 34 participants |
Back to article view | Back to comp.lang.c
References in C jacob navia <jacob@spamsink.net> - 2011-06-24 10:42 +0200
Re: References in C BGB <cr88192@hotmail.com> - 2011-06-24 02:53 -0700
Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-24 22:10 +1200
Re: References in C "BartC" <bc@freeuk.com> - 2011-06-24 11:14 +0100
Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-24 16:59 +0200
Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-24 09:26 -0400
Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-24 20:08 +0200
Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-24 11:40 -0700
Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-24 14:53 -0400
Re: References in C jt@toerring.de (Jens Thoms Toerring) - 2011-06-24 20:44 +0000
Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-24 23:09 +0200
Re: References in C Joe Wright <joewwright@comcast.net> - 2011-06-24 17:38 -0400
Re: References in C "BartC" <bc@freeuk.com> - 2011-06-24 22:58 +0100
Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-25 10:11 +1200
Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-26 17:00 -0500
Re: References in C "BartC" <bc@freeuk.com> - 2011-06-26 22:55 +0100
Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-26 18:25 -0500
Re: References in C "BartC" <bc@freeuk.com> - 2011-06-26 23:38 +0100
Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-26 19:19 -0500
Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-27 01:27 +0200
Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-26 19:13 -0700
Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-27 16:50 +1200
Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-27 06:55 +0200
Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-27 17:10 +1200
Re: References in C lawrence.jones@siemens.com - 2011-06-27 10:04 -0400
Re: References in C jt@toerring.de (Jens Thoms Toerring) - 2011-06-26 22:54 +0000
Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-27 01:29 +0200
Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-26 19:39 -0500
Re: References in C pacman@kosh.dhis.org (Alan Curry) - 2011-06-27 07:16 +0000
Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-27 09:46 +0200
Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-27 12:03 -0400
Re: References in C Stephen Sprunk <stephen@sprunk.org> - 2011-06-27 12:09 -0500
Re: References in C pacman@kosh.dhis.org (Alan Curry) - 2011-06-27 22:16 +0000
Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-27 11:57 -0400
Re: References in C pacman@kosh.dhis.org (Alan Curry) - 2011-06-27 22:21 +0000
Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-28 13:59 +1200
Re: References in C Ike Naar <ike@iceland.freeshell.org> - 2011-06-27 07:05 +0000
Re: References in C jt@toerring.de (Jens Thoms Toerring) - 2011-06-27 20:10 +0000
Re: References in C Stephen Sprunk <stephen@sprunk.org> - 2011-06-27 16:39 -0500
Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-26 15:23 -0700
Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-26 18:57 -0500
Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-26 19:21 -0700
Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-27 09:40 -0400
Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-27 09:00 -0700
Re: References in C pacman@kosh.dhis.org (Alan Curry) - 2011-06-27 23:15 +0000
Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-28 22:50 -0700
Re: References in C Seebs <usenet-nospam@seebs.net> - 2011-06-29 17:46 +0000
Re: References in C Dr Nick <3-nospam@temporary-address.org.uk> - 2011-06-29 20:23 +0100
Re: References in C pacman@kosh.dhis.org (Alan Curry) - 2011-06-29 22:35 +0000
Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-29 16:52 -0700
Re: References in C Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-03 01:31 +0300
Re: References in C Chad <cdalten@gmail.com> - 2011-07-02 17:20 -0700
Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-29 18:54 -0500
Re: References in C Michael Press <rubrum@pacbell.net> - 2011-06-30 10:32 -0700
Re: References in C "io_x" <a@b.c.invalid> - 2011-07-01 10:19 +0200
Re: References in C pacman@kosh.dhis.org (Alan Curry) - 2011-07-01 19:21 +0000
Re: References in C Keith Thompson <kst-u@mib.org> - 2011-07-01 12:31 -0700
Re: References in C pacman@kosh.dhis.org (Alan Curry) - 2011-07-01 19:32 +0000
Re: References in C Keith Thompson <kst-u@mib.org> - 2011-07-01 13:05 -0700
Re: References in C Seebs <usenet-nospam@seebs.net> - 2011-07-01 23:58 +0000
Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-07-01 20:13 -0500
Re: References in C Michael Press <rubrum@pacbell.net> - 2011-07-01 12:44 -0700
Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-07-01 15:57 -0500
Re: References in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-03 14:54 -0700
Re: References in C Michael Press <rubrum@pacbell.net> - 2011-07-03 20:29 -0700
Re: References in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-04 16:05 -0700
Re: References in C Michael Press <rubrum@pacbell.net> - 2011-07-05 08:32 -0700
Re: References in C Lowell Gilbert <lgusenet@be-well.ilk.org> - 2011-07-05 15:34 -0400
Re: References in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-06 15:30 -0700
Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-27 13:27 +1200
Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-27 09:02 -0400
Re: References in C "Joel C. Salomon" <joelcsalomon@gmail.com> - 2011-06-26 18:35 -0400
Re: References in C James Kuyper <jameskuyper@verizon.net> - 2011-06-26 19:11 -0400
Re: References in C "Joel C. Salomon" <joelcsalomon@gmail.com> - 2011-06-28 00:52 -0400
Re: References in C James Kuyper <jameskuyper@verizon.net> - 2011-06-28 07:56 -0400
Re: References in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-06-24 22:52 +0100
Re: References in C jt@toerring.de (Jens Thoms Toerring) - 2011-06-24 23:58 +0000
Re: References in C Tom St Denis <tom@iahu.ca> - 2011-06-24 06:48 -0700
Re: References in C David Resnick <lndresnick@gmail.com> - 2011-06-24 07:14 -0700
Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-24 16:58 +0200
Re: References in C Tom St Denis <tom@iahu.ca> - 2011-06-24 09:08 -0700
Re: References in C Stephen Sprunk <stephen@sprunk.org> - 2011-06-24 11:33 -0500
Re: References in C gazelle@shell.xmission.com (Kenny McCormack) - 2011-06-24 17:47 +0000
Re: References in C JG <jgrove24@hotmail.com> - 2011-07-01 14:24 -0700
Re: References in C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-06-25 04:39 -0700
Re: References in C BGB <cr88192@hotmail.com> - 2011-06-25 16:15 -0700
Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-26 11:27 +1200
Re: References in C BGB <cr88192@hotmail.com> - 2011-06-25 19:13 -0700
Re: References in C cri@tiac.net (Richard Harter) - 2011-06-26 04:22 +0000
Re: References in C Robert Wessel <robertwessel2@yahoo.com> - 2011-06-26 01:31 -0500
Re: References in C BGB <cr88192@hotmail.com> - 2011-06-26 00:03 -0700
Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-26 13:54 -0500
Re: References in C luser- -droog <mijoryx@yahoo.com> - 2011-07-07 11:19 -0700
Re: References in C Dr Nick <3-nospam@temporary-address.org.uk> - 2011-06-26 08:15 +0100
Re: References in C Ike Naar <ike@sverige.freeshell.org> - 2011-06-24 16:08 +0000
Re: References in C Tom St Denis <tom@iahu.ca> - 2011-06-24 11:12 -0700
Re: References in C Ike Naar <ike@iceland.freeshell.org> - 2011-06-24 21:42 +0000
Re: References in C Stephen Sprunk <stephen@sprunk.org> - 2011-06-24 11:49 -0500
Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-24 13:17 -0700
Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-24 16:46 -0400
Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-24 14:32 -0700
Re: References in C Gareth Owen <gwowen@gmail.com> - 2011-06-25 09:39 +0100
Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-07-04 17:38 -0400
Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-24 16:33 -0400
Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-24 23:04 +0200
Re: References in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-26 17:53 -0700
Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-27 17:04 +1200
Re: References in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-27 14:28 -0700
Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-28 14:11 +1200
Re: References in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-28 16:27 -0700
Re: References in C Michael Press <rubrum@pacbell.net> - 2011-06-29 13:41 -0700
Re: References in C Seebs <usenet-nospam@seebs.net> - 2011-06-29 21:15 +0000
Re: References in C Michael Press <rubrum@pacbell.net> - 2011-06-30 09:26 -0700
Re: References in C Seebs <usenet-nospam@seebs.net> - 2011-06-30 20:55 +0000
Re: References in C Michael Press <rubrum@pacbell.net> - 2011-06-30 16:20 -0700
Re: References in C Seebs <usenet-nospam@seebs.net> - 2011-06-30 23:45 +0000
Re: References in C James Kuyper <jameskuyper@verizon.net> - 2011-07-01 07:58 -0400
Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-27 10:43 +0200
Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-27 08:32 -0700
Re: References in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-28 11:01 -0700
Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-28 22:17 +0200
Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-29 09:05 +1200
Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-28 22:24 -0700
Re: References in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-29 01:07 -0700
Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-29 21:16 +1200
Re: References in C Seebs <usenet-nospam@seebs.net> - 2011-06-29 17:46 +0000
Re: References in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-29 12:19 -0700
Re: References in C sandeep <nospam@nospam.com> - 2011-07-03 20:53 +0000
Re: References in C Chad <cdalten@gmail.com> - 2011-07-03 14:02 -0700
Re: References in C Keith Thompson <kst-u@mib.org> - 2011-07-03 14:33 -0700
Re: References in C jacob navia <jacob@spamsink.net> - 2011-07-04 00:22 +0200
Re: References in C Keith Thompson <kst-u@mib.org> - 2011-07-04 13:41 -0700
Re: References in C gazelle@shell.xmission.com (Kenny McCormack) - 2011-07-04 00:00 +0000
Re: References in C Seebs <usenet-nospam@seebs.net> - 2011-07-04 00:20 +0000
Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-07-04 17:43 -0400
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-06-26 19:13 -0700 |
| Message-ID | <ln62nsaune.fsf@nuthaus.mib.org> |
| In reply to | #7000 |
jacob navia <jacob@spamsink.net> writes:
[...]
> References must be initialized to an object when they are defined. They
> are always bound to the same object by definition, there are no
> assertions.
>
> You can't write:
> int & a;
>
> You MUST write
>
> int p = 42;
> int & a = p;
>
> If you write
> int & a = 76;
>
> I will generate an internal constant variable initialized to 76 and
> give that address to the reference.
Ok, then that's a difference between lcc-win's references and C++
references. In C++, you can only initialize reference to an lvalue.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-06-27 16:50 +1200 |
| Message-ID | <96qghgF2dgU3@mid.individual.net> |
| In reply to | #7008 |
On 06/27/11 02:13 PM, Keith Thompson wrote: > jacob navia<jacob@spamsink.net> writes: > [...] >> References must be initialized to an object when they are defined. They >> are always bound to the same object by definition, there are no >> assertions. >> >> You can't write: >> int& a; >> >> You MUST write >> >> int p = 42; >> int& a = p; >> >> If you write >> int& a = 76; >> >> I will generate an internal constant variable initialized to 76 and >> give that address to the reference. > > Ok, then that's a difference between lcc-win's references and C++ > references. In C++, you can only initialize reference to an lvalue. But you can initialise a const reference with an rvalue, which makes sense. I hope Jacob made a typo, trying to change the value of 76 would be interesting to say the least! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-06-27 06:55 +0200 |
| Message-ID | <iu92fe$fhh$1@speranza.aioe.org> |
| In reply to | #7016 |
Le 27/06/11 06:50, Ian Collins a écrit : > But you can initialise a const reference with an rvalue, which makes > sense. I hope Jacob made a typo, trying to change the value of 76 would > be interesting to say the least! > Of course you do not change the value of 76, I generate a (hidden) object that holds an integer 76, then I assign to the reference the address of that hidden object.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-06-27 17:10 +1200 |
| Message-ID | <96qhm3F2dgU5@mid.individual.net> |
| In reply to | #7017 |
On 06/27/11 04:55 PM, jacob navia wrote: > Le 27/06/11 06:50, Ian Collins a écrit : > >> But you can initialise a const reference with an rvalue, which makes >> sense. I hope Jacob made a typo, trying to change the value of 76 would >> be interesting to say the least! >> > Of course you do not change the value of 76, I generate a (hidden) > object that holds an integer 76, then I assign to the reference > the address of that hidden object. Wouldn't it be better to restrict non-const reference initialisation to lvalues? That would be more intuitive to most people. If you want a reference to an rvalue, use a const reference. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | lawrence.jones@siemens.com |
|---|---|
| Date | 2011-06-27 10:04 -0400 |
| Message-ID | <u8fmd8-0m7.ln1@jones.homeip.net> |
| In reply to | #7016 |
Ian Collins <ian-news@hotmail.com> wrote: > > But you can initialise a const reference with an rvalue, which makes > sense. I hope Jacob made a typo, trying to change the value of 76 would > be interesting to say the least! Hey, you can do it in many versions of FORTRAN, why not C as well? :-) -- Larry Jones Shut up and go get me some antiseptic. -- Calvin
[toc] | [prev] | [next] | [standalone]
| From | jt@toerring.de (Jens Thoms Toerring) |
|---|---|
| Date | 2011-06-26 22:54 +0000 |
| Message-ID | <96prkiFafhU1@mid.uni-berlin.de> |
| In reply to | #6992 |
Shao Miller <sha0.miller@gmail.com> wrote:
> On 6/26/2011 4:55 PM, BartC wrote:
> >
> > "Shao Miller" <sha0.miller@gmail.com> wrote in message
> > news:iu86kn$att$1@dont-email.me...
> >> On 6/24/2011 5:11 PM, Ian Collins wrote:
> >>> On 06/25/11 09:38 AM, Joe Wright wrote:
> >>>> On 6/24/2011 17:09, jacob navia wrote:
> >>>>
> >>>> [ Snipping everything }
> >>>>
> >>>> What advantage does C++ reference have? None say I. Pass&var and accept
> >>>> *var and all is solved simply. Tell me where I'm wrong.
> >>>
> >>> For one, you don't have to test for NULL,
> >>
> >> (By which you obviously mean a null pointer value. I don't use 'if (p ==
> >> NULL)' but 'if (!p)'.)
> >>
> >> But I still don't fully perceive this particular benefit, here.
> >
> > The benefit (as I understand it) is that the code doesn't even need to be
> > aware that something is a pointer:
> >
> > a = b+c*d;
> >
> > instead of:
> >
> > if(a && b && c && d) *a=*b+*c*(*d);
> > else ... /* big headache... */
> >
> That mixes the two points or seems to have more to do with the second
> point that Mr. I. Collins had made, as far as I can tell. I was
> specifically responding to the first point with that portion of the
> response that you quoted.
> A callee checking for a null pointer parameter needn't happen if we
> assume that a callee is never passed a null pointer argument, with or
> without references, right? As a language feature, I don't understand
> "references" as providing an advantage with regards to this.
> Do these "references" inject an implicit assertion before every call,
> thus crashing the program (during execution) in the caller before
> reaching the callee?
No, it's much simpler (at least if Jacob implemented it the
same way it's done in C++): you can only create a reference
to an existing object since it must be initialized at crea-
tion and a reference can't be made to reference anything else
after it has been created. So neither
int &ir;
is legal (missing initialization) nor
int i, j;
int &ir = i;
ir = j;
(attempt to change what the reference references). This also
implies that the reference never has a "wider scope" than
what it references and it's thus guaranteed that when what
the reference "points" to goes out of scope also the refe-
rence does. That way you simply have no chance to pass on
a reference that does not "point" to an existing object to
a function. Thus you don't have to worry in the callee that
you might have received the equivalent of a NULL pointer.
Of course, that makes references as arguments unsuitable
for cases where receiving a "NULL pointer" is actually a
reasonable possibility.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-06-27 01:29 +0200 |
| Message-ID | <iu8fda$fen$2@speranza.aioe.org> |
| In reply to | #6995 |
Le 27/06/11 00:54, Jens Thoms Toerring a écrit : > > No, it's much simpler (at least if Jacob implemented it the > same way it's done in C++): Yes, I do not want any incompatible semantics with c++ in this area. Their design is already debugged.
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-06-26 19:39 -0500 |
| Message-ID | <iu8g01$7nu$1@dont-email.me> |
| In reply to | #6995 |
On 6/26/2011 5:54 PM, Jens Thoms Toerring wrote:
> Shao Miller<sha0.miller@gmail.com> wrote:
>> On 6/26/2011 4:55 PM, BartC wrote:
>>>
>>> "Shao Miller"<sha0.miller@gmail.com> wrote in message
>>> news:iu86kn$att$1@dont-email.me...
>>>> On 6/24/2011 5:11 PM, Ian Collins wrote:
>>>>> On 06/25/11 09:38 AM, Joe Wright wrote:
>>>>>> On 6/24/2011 17:09, jacob navia wrote:
>>>>>>
>>>>>> [ Snipping everything }
>>>>>>
>>>>>> What advantage does C++ reference have? None say I. Pass&var and accept
>>>>>> *var and all is solved simply. Tell me where I'm wrong.
>>>>>
>>>>> For one, you don't have to test for NULL,
>>>>
>>>> (By which you obviously mean a null pointer value. I don't use 'if (p ==
>>>> NULL)' but 'if (!p)'.)
>>>>
>>>> But I still don't fully perceive this particular benefit, here.
>>>
>>> The benefit (as I understand it) is that the code doesn't even need to be
>>> aware that something is a pointer:
>>>
>>> a = b+c*d;
>>>
>>> instead of:
>>>
>>> if(a&& b&& c&& d) *a=*b+*c*(*d);
>>> else ... /* big headache... */
>>>
>
>> That mixes the two points or seems to have more to do with the second
>> point that Mr. I. Collins had made, as far as I can tell. I was
>> specifically responding to the first point with that portion of the
>> response that you quoted.
>
>> A callee checking for a null pointer parameter needn't happen if we
>> assume that a callee is never passed a null pointer argument, with or
>> without references, right? As a language feature, I don't understand
>> "references" as providing an advantage with regards to this.
>
>> Do these "references" inject an implicit assertion before every call,
>> thus crashing the program (during execution) in the caller before
>> reaching the callee?
>
> No, it's much simpler (at least if Jacob implemented it the
> same way it's done in C++): you can only create a reference
> to an existing object since it must be initialized at crea-
> tion and a reference can't be made to reference anything else
> after it has been created. So neither
>
> int&ir;
>
> is legal (missing initialization) nor
>
> int i, j;
> int&ir = i;
> ir = j;
>
> (attempt to change what the reference references).
That's not the same point as not having to test a pointer for having a
null pointer value, though. Already discussed elsethread, with
pointers, you can have:
int i, * const ip = &i;
and 'ip' should always point to the same entity.
> This also
> implies that the reference never has a "wider scope" than
> what it references and it's thus guaranteed that when what
> the reference "points" to goes out of scope also the refe-
> rence does.
I believe that by "scope," you mean "lifetime." That seems pretty
similar to a pointer value becoming "indeterminate" when a pointed-to
object reaches the end of its lifetime.
> That way you simply have no chance to pass on
> a reference that does not "point" to an existing object to
> a function.
But this just seems to shuffle around any point of failure or undefined
behaviour, doesn't it?
void func(int & i) {
++i;
return;
}
int main(void) {
int * ip;
ip = malloc(sizeof *ip);
/* 'ip' might be a null pointer value */
free(ip);
/* 'ip' could be null or indeterminate */
func(*ip); /* U. B. */
return 0;
}
> Thus you don't have to worry in the callee that
> you might have received the equivalent of a NULL pointer.
> Of course, that makes references as arguments unsuitable
> for cases where receiving a "NULL pointer" is actually a
> reasonable possibility.
But you don't have to check for null-valued pointer parameters, either,
so how is this an advantage?
I want to mention that I think the "C reference types" idea seems nice
in some ways, but not in _this_ way (unless it becomes clear). :)
[toc] | [prev] | [next] | [standalone]
| From | pacman@kosh.dhis.org (Alan Curry) |
|---|---|
| Date | 2011-06-27 07:16 +0000 |
| Message-ID | <iu9aos$vjt$1@speranza.aioe.org> |
| In reply to | #7003 |
In article <iu8g01$7nu$1@dont-email.me>,
Shao Miller <sha0.miller@gmail.com> wrote:
>On 6/26/2011 5:54 PM, Jens Thoms Toerring wrote:
>
>> That way you simply have no chance to pass on
>> a reference that does not "point" to an existing object to
>> a function.
>
>But this just seems to shuffle around any point of failure or undefined
>behaviour, doesn't it?
Yes, and it's even easier to demonstrate than your example.
void foo(int &iref)
{
iref = 42;
}
int main(void)
{
int *whoops = 0;
foo(*whoops);
return 0;
}
The use of the C++ reference didn't make testing for NULL unnecessary; it
merely made testing for NULL impossible.
--
Alan Curry
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-06-27 09:46 +0200 |
| Message-ID | <iu9chi$3q9$1@speranza.aioe.org> |
| In reply to | #7027 |
Le 27/06/11 09:16, Alan Curry a écrit :
> void foo(int&iref)
> {
> iref = 42;
> }
>
> int main(void)
> {
> int *whoops = 0;
> foo(*whoops);
> return 0;
> }
>
> The use of the C++ reference didn't make testing for NULL unnecessary; it
> merely made testing for NULL impossible.
>
??????
This would crash in the calling function, not in the called function,
making the crash one step closer to the source of the problem.
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-06-27 12:03 -0400 |
| Message-ID | <iua9nr$loj$1@dont-email.me> |
| In reply to | #7029 |
On 6/27/2011 03:46, jacob navia wrote:
> Le 27/06/11 09:16, Alan Curry a écrit :
>> void foo(int &iref)
>> {
>> iref = 42;
>> }
>>
>> int main(void)
>> {
>> int *whoops = 0;
>> foo(*whoops);
>> return 0;
>> }
>>
>> The use of the C++ reference didn't make testing for NULL unnecessary; it
>> merely made testing for NULL impossible.
>>
>
> ??????
> This would crash in the calling function, not in the called function,
> making the crash one step closer to the source of the problem.
>
(Or at least invoke undefined behaviour "sooner"; a crash mightn't be
mandated, right?)
I'm a little curious about the C++ Standard text for reference
initialization. I'm curious, for instance, if '*whoops' is actually
evaluated/read (please don't confuse with 'whoops', which I assume would
be) or if its "lvalue-ness" is simply "used." But maybe I'll look it up
later.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2011-06-27 12:09 -0500 |
| Message-ID | <iuadgb$i1n$1@dont-email.me> |
| In reply to | #7029 |
On 27-Jun-11 02:46, jacob navia wrote:
> Le 27/06/11 09:16, Alan Curry a écrit :
>> void foo(int&iref)
>> {
>> iref = 42;
>> }
>>
>> int main(void)
>> {
>> int *whoops = 0;
>> foo(*whoops);
>> return 0;
>> }
>>
>> The use of the C++ reference didn't make testing for NULL unnecessary; it
>> merely made testing for NULL impossible.
>
> ??????
> This would crash in the calling function, not in the called function,
> making the crash one step closer to the source of the problem.
Why would it crash in the caller? The caller would simply take the
address of *whoops (&*whoops, which simplifies to whoops) and pass it to
the function. whoops is only dereferenced in the callee.
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | pacman@kosh.dhis.org (Alan Curry) |
|---|---|
| Date | 2011-06-27 22:16 +0000 |
| Message-ID | <iuavfi$4qb$1@speranza.aioe.org> |
| In reply to | #7029 |
In article <iu9chi$3q9$1@speranza.aioe.org>,
jacob navia <jacob@jspamsink.org> wrote:
>Le 27/06/11 09:16, Alan Curry a écrit :
>> void foo(int&iref)
>> {
>> iref = 42;
>> }
>>
>> int main(void)
>> {
>> int *whoops = 0;
>> foo(*whoops);
>> return 0;
>> }
>>
>> The use of the C++ reference didn't make testing for NULL unnecessary; it
>> merely made testing for NULL impossible.
>>
>
>??????
>This would crash in the calling function, not in the called function,
>making the crash one step closer to the source of the problem.
>
When I tried it with g++ the segfault happened on the "iref = 42" line.
That's what I expected, since this reference business is just syntactic
sugar, and underneath the hood the *whoops in the caller is really &*whoops,
with the & canceling the * so there's not really any memory access there, and
the iref assignment is really doing a memory store to the location pointed to
by the function argument, which is a pointer.
The reference stuff just disguises everything.
If you have a compiler than can point out the error on the foo(*whoops) line,
that's nice for you I guess. Even better if it does the check at runtime,
since any real problems of this nature would probably involve a variable
whose null-ness isn't known at compile time.
This should thwart any static analysis:
int *whoops = rand()==666 ? malloc(sizeof(int)) : NULL;
--
Alan Curry
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-06-27 11:57 -0400 |
| Message-ID | <iua9cs$isu$1@dont-email.me> |
| In reply to | #7027 |
On 6/27/2011 03:16, Alan Curry wrote:
> In article<iu8g01$7nu$1@dont-email.me>,
> Shao Miller<sha0.miller@gmail.com> wrote:
>> On 6/26/2011 5:54 PM, Jens Thoms Toerring wrote:
>>
>>> That way you simply have no chance to pass on
>>> a reference that does not "point" to an existing object to
>>> a function.
>>
>> But this just seems to shuffle around any point of failure or undefined
>> behaviour, doesn't it?
>
> Yes, and it's even easier to demonstrate than your example.
>
> void foo(int&iref)
> {
> iref = 42;
> }
>
> int main(void)
> {
> int *whoops = 0;
> foo(*whoops);
> return 0;
> }
>
"Easier": Agreed. Similar example given elsethread, although it was
missing an #include; oops.
On 6/26/2011 19:57, Shao Miller wrote:
> void func(int & i) {
> ++i;
> return;
> }
>
> int main(void) {
> int * ip = NULL;
> func(*ip);
> return 0;
> }
On 6/27/2011 03:16, Alan Curry wrote:
> The use of the C++ reference didn't make testing for NULL unnecessary; it
> merely made testing for NULL impossible.
>
What about with:
#include <assert.h>
int main(void) {
int * ip = 0;
int & i = *ip;
assert(&i);
return 0;
}
Does the assertion check for a, let's say, "null reference"?
[toc] | [prev] | [next] | [standalone]
| From | pacman@kosh.dhis.org (Alan Curry) |
|---|---|
| Date | 2011-06-27 22:21 +0000 |
| Message-ID | <iuavpt$5hl$1@speranza.aioe.org> |
| In reply to | #7074 |
In article <iua9cs$isu$1@dont-email.me>,
Shao Miller <sha0.miller@gmail.com> wrote:
>
>On 6/27/2011 03:16, Alan Curry wrote:
>> The use of the C++ reference didn't make testing for NULL unnecessary; it
>> merely made testing for NULL impossible.
>>
>
>What about with:
>
> #include <assert.h>
>
> int main(void) {
> int * ip = 0;
> int & i = *ip;
> assert(&i);
> return 0;
> }
>
>Does the assertion check for a, let's say, "null reference"?
You're right. It's not impossible to check for a null reference. You just
have to think outside the box.
#include <stdio.h>
void foo(int &iref)
{
if(&iref == NULL) {
printf("&iref is null. How about that!\n");
return;
}
iref = 42;
}
int main(void)
{
int *whoops = 0;
foo(*whoops);
return 0;
}
I'm sure this is all formally undefined. But it shows that references are
purely an alternate syntax for pointers and don't provide any real
"protection" against unexpected NULLs. You're just depending on your caller
to have already done the check.
All functions depend on their callers being sane; new syntax won't change
that.
--
Alan Curry
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-06-28 13:59 +1200 |
| Message-ID | <96sqtbF2dgU9@mid.individual.net> |
| In reply to | #7108 |
On 06/28/11 10:21 AM, Alan Curry wrote:
> In article<iua9cs$isu$1@dont-email.me>,
> Shao Miller<sha0.miller@gmail.com> wrote:
>>
>> On 6/27/2011 03:16, Alan Curry wrote:
>>> The use of the C++ reference didn't make testing for NULL unnecessary; it
>>> merely made testing for NULL impossible.
>>>
>>
>> What about with:
>>
>> #include<assert.h>
>>
>> int main(void) {
>> int * ip = 0;
>> int& i = *ip;
>> assert(&i);
>> return 0;
>> }
>>
>> Does the assertion check for a, let's say, "null reference"?
>
> You're right. It's not impossible to check for a null reference. You just
> have to think outside the box.
>
> #include<stdio.h>
>
> void foo(int&iref)
> {
> if(&iref == NULL) {
> printf("&iref is null. How about that!\n");
> return;
> }
> iref = 42;
> }
>
> int main(void)
> {
> int *whoops = 0;
> foo(*whoops);
> return 0;
> }
>
> I'm sure this is all formally undefined. But it shows that references are
> purely an alternate syntax for pointers and don't provide any real
> "protection" against unexpected NULLs. You're just depending on your caller
> to have already done the check.
>
> All functions depend on their callers being sane; new syntax won't change
> that.
>
The more postings I read on this thread, the more I'm coming round to
the opinion that references are probably not such a good idea in C after
all.
In C++, references are often used as return values, so there is seldom
any mixing of references and pointers. Reference returns are only
practical if there is a means of indicating an error (exceptions in
C++). Without viable reference returns, references will have limited
utility.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2011-06-27 07:05 +0000 |
| Message-ID | <slrn3vfsj0gat2.9js.ike@iceland.freeshell.org> |
| In reply to | #6995 |
On 2011-06-26, Jens Thoms Toerring <jt@toerring.de> wrote: > No, it's much simpler (at least if Jacob implemented it the > same way it's done in C++): you can only create a reference > to an existing object since it must be initialized at crea- > tion and a reference can't be made to reference anything else > after it has been created. So neither > > int &ir; > > is legal (missing initialization) nor > > int i, j; > int &ir = i; > ir = j; > > (attempt to change what the reference references). [...] In C++ the last one is not an attempt to change ``ir'' into a reference to ``j'' (which is, as you said, impossible). Instead, it's an ordinary integer assignment that copies the value of ``j'' into ``ir'' (which is still bound to ``i''). It has the same effect as ``i = j;''.
[toc] | [prev] | [next] | [standalone]
| From | jt@toerring.de (Jens Thoms Toerring) |
|---|---|
| Date | 2011-06-27 20:10 +0000 |
| Message-ID | <96s6dpFq52U1@mid.uni-berlin.de> |
| In reply to | #7025 |
Ike Naar <ike@iceland.freeshell.org> wrote:
> On 2011-06-26, Jens Thoms Toerring <jt@toerring.de> wrote:
> > No, it's much simpler (at least if Jacob implemented it the
> > same way it's done in C++): you can only create a reference
> > to an existing object since it must be initialized at crea-
> > tion and a reference can't be made to reference anything else
> > after it has been created. So neither
> >
> > int &ir;
> >
> > is legal (missing initialization) nor
> >
> > int i, j;
> > int &ir = i;
> > ir = j;
> >
> > (attempt to change what the reference references). [...]
> In C++ the last one is not an attempt to change ``ir'' into a
> reference to ``j'' (which is, as you said, impossible).
> Instead, it's an ordinary integer assignment that copies the value
> of ``j'' into ``ir'' (which is still bound to ``i''). It has the
> same effect as ``i = j;''.
Uuups, yes, that wasn't real C++ - there actually isn't any
syntax for changing what a reference "points" to;-)
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2011-06-27 16:39 -0500 |
| Message-ID | <iuatb7$9bs$1@dont-email.me> |
| In reply to | #6995 |
On 26-Jun-11 17:54, Jens Thoms Toerring wrote: > No, it's much simpler (at least if Jacob implemented it the > same way it's done in C++): you can only create a reference > to an existing object since it must be initialized at crea- > tion and a reference can't be made to reference anything else > after it has been created. So neither > > int &ir; > > is legal (missing initialization) nor > > int i, j; > int &ir = i; > ir = j; > > (attempt to change what the reference references). Is there a good reason why you can't? Logically, &ir = j; should do that, following the syntax of reference initialization. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-06-26 15:23 -0700 |
| Message-ID | <lnaad4b5bo.fsf@nuthaus.mib.org> |
| In reply to | #6987 |
Shao Miller <sha0.miller@gmail.com> writes:
> On 6/24/2011 5:11 PM, Ian Collins wrote:
>> On 06/25/11 09:38 AM, Joe Wright wrote:
>>> On 6/24/2011 17:09, jacob navia wrote:
>>>
>>> [ Snipping everything }
>>>
>>> What advantage does C++ reference have? None say I. Pass&var and accept
>>> *var and all is solved simply. Tell me where I'm wrong.
>>
>> For one, you don't have to test for NULL,
>
> (By which you obviously mean a null pointer value. I don't use 'if (p
> == NULL)' but 'if (!p)'.)
I prefer to be more explicit, but your mileage obviously varies.
> But I still don't fully perceive this particular benefit, here.
>
> For "static" and "automatic" objects, if you pass '&x', there can be
> little doubt that the called function gets a valid "reference" to an
> object. This can be observed at translation time.
>
> For "allocated" objects, if we check for allocation success (not
> everyone does, of course), then there should be no doubt about having a
> valid object reference.
Sure, the *caller* should know whether a pointer value it's passing is,
or might be, or definitely isn't a null pointer. But the function
itself doesn't.
Sometimes a null pointer is a valid value. Sometimes it isn't.
Reference parameters (in languages that support them) are for the
latter case.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web