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 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-06-24 10:42 +0200 |
| Subject | References in C |
| Message-ID | <iu1iku$4k9$1@speranza.aioe.org> |
The lcc-win compiler is an experimental compiler to promote the
development of C as a language. Contrary to the main trends of language
design this days, lcc-win considers C not a dead language but a language
that can evolve and propose new features.
In this context, one of the extensions that lcc-win supports is
references, where the design is largely inspired from the C++ design.
What are references?
In fact, a reference is just a pointer. It is different from plain
pointers in two ways:
(1) It is always assigned to a concrete object when it is defined.
(2) Once defined, it will always point to that same object. It can't
be changed to point into another object.
(3) It is used with the '.' notation, as if it weren't a pointer.
(4) Instead of "*' the symbol "&" is used:
int i = 23;
int &IntReference = i;
As always in this proposals, the problems hide in the details. For
instance, several days ago someone complained that a reference to
void would not compile, but a pointer to void would. This prompted
me to correct a problem in my implementation: I should have forbidden to
build references to void!
The problem is when defining a reference but when you pass a reference
to a function:
int fn(void &ref);
In this case there is no initialization (that would explode immediately)
but just a definition without any initialization. The compiler must
check, then, that the reference is not to a void pointer.
Since the object pointed to by a reference can't change, many people
think that the value can't never change but that is wrong. Consider:
#include <stdio.h>
int main(void)
{
int i = 23;
int &pi = i;
i = 3;
printf("%d\n",pi);
}
The reference is initialized to an integer whose value is 23.
If the integer changes its value, the reference (like all other
pointers) changes its value also.
The advantages of using references are that they are never NULL,
and that they always point to the same object, two important
things less to test. The only (orthodox) way of declaring a non-NULL
pointer in an argument list is now:
int fn(int arg[static 1]);
This declares that the "arg" argument will have at least one integer
Few people know this, and it wasn't much explained when C99 introduced
it.
jacob
[toc] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-06-24 02:53 -0700 |
| Message-ID | <iu1n2b$lok$1@news.albasani.net> |
| In reply to | #6809 |
On 6/24/2011 1:42 AM, jacob navia wrote:
> The lcc-win compiler is an experimental compiler to promote the
> development of C as a language. Contrary to the main trends of language
> design this days, lcc-win considers C not a dead language but a language
> that can evolve and propose new features.
>
> In this context, one of the extensions that lcc-win supports is
> references, where the design is largely inspired from the C++ design.
>
a partial risk though is that C + bunches-of-extensions is no longer C,
rather, another C derived language (in a similar manner to C++ or
Objective-C, which are also not strictly C).
>
> What are references?
>
> In fact, a reference is just a pointer. It is different from plain
> pointers in two ways:
>
> (1) It is always assigned to a concrete object when it is defined.
> (2) Once defined, it will always point to that same object. It can't
> be changed to point into another object.
> (3) It is used with the '.' notation, as if it weren't a pointer.
> (4) Instead of "*' the symbol "&" is used:
> int i = 23;
> int &IntReference = i;
>
> As always in this proposals, the problems hide in the details. For
> instance, several days ago someone complained that a reference to
> void would not compile, but a pointer to void would. This prompted
> me to correct a problem in my implementation: I should have forbidden to
> build references to void!
>
> The problem is when defining a reference but when you pass a reference
> to a function:
> int fn(void &ref);
> In this case there is no initialization (that would explode immediately)
> but just a definition without any initialization. The compiler must
> check, then, that the reference is not to a void pointer.
>
> Since the object pointed to by a reference can't change, many people
> think that the value can't never change but that is wrong. Consider:
>
> #include <stdio.h>
> int main(void)
> {
> int i = 23;
> int &pi = i;
>
> i = 3;
> printf("%d\n",pi);
> }
>
> The reference is initialized to an integer whose value is 23.
> If the integer changes its value, the reference (like all other
> pointers) changes its value also.
>
> The advantages of using references are that they are never NULL,
> and that they always point to the same object, two important
> things less to test. The only (orthodox) way of declaring a non-NULL
> pointer in an argument list is now:
>
> int fn(int arg[static 1]);
>
> This declares that the "arg" argument will have at least one integer
> Few people know this, and it wasn't much explained when C99 introduced
> it.
>
going OT:
interestingly, in my own current language (more closely related to
JavaScript and ActionScript), I ended up giving references a "look and
feel" more like that of C pointers.
basically, the caller needs to use "&" to pass an argument to a
reference, and by default (no '&' in the argument list) it would be
needed to use '*' to access/assign them. if '&' is given, it means to
insert an implicit '*' on access, and later could also insert basic
sanity checks (barf if the argument is not "sane" when calling the
function).
as-is, I figured doing calls like "foo(&x);" to be a reasonable
trade-off (it serves a similar role to 'ref' in C#).
note that, unlike C, these are not raw pointers, rather a
boxed-pointer-type (some languages use the term "locative" for these
instead of "pointer" or "reference").
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-06-24 22:10 +1200 |
| Message-ID | <96j653Fb9tU4@mid.individual.net> |
| In reply to | #6815 |
On 06/24/11 09:53 PM, BGB wrote: > On 6/24/2011 1:42 AM, jacob navia wrote: >> The lcc-win compiler is an experimental compiler to promote the >> development of C as a language. Contrary to the main trends of language >> design this days, lcc-win considers C not a dead language but a language >> that can evolve and propose new features. >> >> In this context, one of the extensions that lcc-win supports is >> references, where the design is largely inspired from the C++ design. >> > > a partial risk though is that C + bunches-of-extensions is no longer C, > rather, another C derived language (in a similar manner to C++ or > Objective-C, which are also not strictly C). C++--? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2011-06-24 11:14 +0100 |
| Message-ID | <iu1o3t$tst$1@dont-email.me> |
| In reply to | #6809 |
"jacob navia" <jacob@spamsink.net> wrote in message
news:iu1iku$4k9$1@speranza.aioe.org...
> #include <stdio.h>
> int main(void)
> {
> int i = 23;
> int &pi = i;
>
> i = 3;
> printf("%d\n",pi);
> }
This doesn't compile in my lcc-win32 unless I make i static ("addressable
object required" in the int &pi line).
Is this a restriction, or do I need an update?
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-06-24 16:59 +0200 |
| Message-ID | <iu28oc$f60$3@speranza.aioe.org> |
| In reply to | #6820 |
Le 24/06/11 12:14, BartC a écrit :
> "jacob navia" <jacob@spamsink.net> wrote in message
> news:iu1iku$4k9$1@speranza.aioe.org...
>
>> #include <stdio.h>
>> int main(void)
>> {
>> int i = 23;
>> int &pi = i;
>>
>> i = 3;
>> printf("%d\n",pi);
>> }
>
> This doesn't compile in my lcc-win32 unless I make i static
> ("addressable object required" in the int &pi line).
>
> Is this a restriction, or do I need an update?
>
I think you need an update... I introduced this several years
ago... I just compiled that and it works without any problems.
Please do not use it with -ansic though.
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-06-24 09:26 -0400 |
| Message-ID | <iu23ck$4m2$1@dont-email.me> |
| In reply to | #6809 |
On 6/24/2011 04:42, jacob navia wrote:
> The lcc-win compiler is an experimental compiler to promote the
> development of C as a language. Contrary to the main trends of language
> design this days, lcc-win considers C not a dead language but a language
> that can evolve and propose new features.
> ...
> In fact, a reference is just a pointer. It is different from plain pointers in two ways:
>
> (1) It is always assigned to a concrete object when it is defined.
> (2) Once defined, it will always point to that same object. It can't
> be changed to point into another object.
> (3) It is used with the '.' notation, as if it weren't a pointer.
> (4) Instead of "*' the symbol "&" is used:
> int i = 23;
> int &IntReference = i;
(I think you meant "four ways". You must have started with 2 and then
remembered 2 more. ;) )
So I'm guessing that if you have:
void foo(struct xxx & bar) { /* ... */ }
If you have an object with "allocated" storage duration, you'd do:
struct xxx * bar;
/* ...See below... */
foo(*bar_ptr);
in order for 'foo' to work with the pointed-to object, right?
But before you perform the call, you must:
- Allocate the object
- Check that the allocation succeeds
If you do these things before calling 'foo', then 'foo' needn't check
for a null pointer, right? For:
void foo(struct xxx * bar) { /* ... */ }
"static" and "automatic" objects can have their addresses passed with
'&', right?
So this seems to be along the lines of #1, above.
Then there's also:
void foo(struct xxx * const bar) { /* ... */ }
and:
int i;
int * const ip = &i;
which appear to be along the lines of #2, above.
Am I understanding these two points correctly?
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-06-24 20:08 +0200 |
| Message-ID | <iu2jrj$uel$1@speranza.aioe.org> |
| In reply to | #6830 |
Le 24/06/11 15:26, Shao Miller a écrit :
> So I'm guessing that if you have:
>
> void foo(struct xxx & bar) { /* ... */ }
>
> If you have an object with "allocated" storage duration, you'd do:
>
> struct xxx * bar;
> /* ...See below... */
> foo(*bar_ptr);
>
> in order for 'foo' to work with the pointed-to object, right?
>
yes.
> But before you perform the call, you must:
> - Allocate the object
> - Check that the allocation succeeds
>
Yes. You must pass an object, not a pointer.
> If you do these things before calling 'foo', then 'foo' needn't check
> for a null pointer, right? For:
>
> void foo(struct xxx * bar) { /* ... */ }
>
> "static" and "automatic" objects can have their addresses passed with
> '&', right?
>
Yes. For immediate constants (foo(5);) the compiler must generate a
temporary object and pass its address.
> So this seems to be along the lines of #1, above.
>
> Then there's also:
>
> void foo(struct xxx * const bar) { /* ... */ }
>
> and:
>
> int i;
> int * const ip = &i;
>
> which appear to be along the lines of #2, above.
>
> Am I understanding these two points correctly?
I do not understand the second. Can you explain in more depth?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-06-24 11:40 -0700 |
| Message-ID | <ln4o3fdqdq.fsf@nuthaus.mib.org> |
| In reply to | #6852 |
jacob navia <jacob@spamsink.net> writes:
> Le 24/06/11 15:26, Shao Miller a écrit :
>> So I'm guessing that if you have:
>>
>> void foo(struct xxx & bar) { /* ... */ }
>>
>> If you have an object with "allocated" storage duration, you'd do:
>>
>> struct xxx * bar;
>> /* ...See below... */
>> foo(*bar_ptr);
>>
>> in order for 'foo' to work with the pointed-to object, right?
>>
>
> yes.
[snip more questions and answers]
Perhaps it would save time to explain how lcc-win's references differ
from standard C++ references, if at all.
--
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 | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-06-24 14:53 -0400 |
| Message-ID | <iu2mie$bk3$1@dont-email.me> |
| In reply to | #6852 |
On 6/24/2011 14:08, jacob navia wrote:
> Le 24/06/11 15:26, Shao Miller a écrit :
>> So I'm guessing that if you have:
>>
>> void foo(struct xxx & bar) { /* ... */ }
>>
>> If you have an object with "allocated" storage duration, you'd do:
>>
>> struct xxx * bar;
>> /* ...See below... */
>> foo(*bar_ptr);
>>
>> in order for 'foo' to work with the pointed-to object, right?
>>
>
> yes.
>
Thanks. :)
>
>> But before you perform the call, you must:
>> - Allocate the object
>> - Check that the allocation succeeds
>>
>
> Yes. You must pass an object, not a pointer.
>
>> If you do these things before calling 'foo', then 'foo' needn't check
>> for a null pointer, right? For:
>>
>> void foo(struct xxx * bar) { /* ... */ }
>>
>> "static" and "automatic" objects can have their addresses passed with
>> '&', right?
>>
>
> Yes. For immediate constants (foo(5);) the compiler must generate a
> temporary object and pass its address.
>
Aha. I'm glad you brought this up. So, assuming the 'foo' above taking
a pointer (not the one above that, taking an lcc-win reference), this is
something that might be difficult with C89, but could be facilitated by C99:
foo(&(int){5});
>
>> So this seems to be along the lines of #1, above.
>>
>> Then there's also:
>>
>> void foo(struct xxx * const bar) { /* ... */ }
>>
>> and:
>>
>> int i;
>> int * const ip = &i;
>>
>> which appear to be along the lines of #2, above.
>>
>> Am I understanding these two points correctly?
>
> I do not understand the second. Can you explain in more depth?
Well your point #2 was that references always refer to the same object.
I'm asking if that's akin to 'ip', above. Does that make sense?
[toc] | [prev] | [next] | [standalone]
| From | jt@toerring.de (Jens Thoms Toerring) |
|---|---|
| Date | 2011-06-24 20:44 +0000 |
| Message-ID | <96kba8FvolU1@mid.uni-berlin.de> |
| In reply to | #6852 |
jacob navia <jacob@spamsink.net> wrote:
> Le 24/06/11 15:26, Shao Miller a écrit :
> > So I'm guessing that if you have:
> >
> > void foo(struct xxx & bar) { /* ... */ }
> >
> > If you have an object with "allocated" storage duration, you'd do:
> >
> > struct xxx * bar;
> > /* ...See below... */
> > foo(*bar_ptr);
> >
> > in order for 'foo' to work with the pointed-to object, right?
> yes.
> > But before you perform the call, you must:
> > - Allocate the object
> > - Check that the allocation succeeds
> Yes. You must pass an object, not a pointer.
Just out of curiosity: how are things handled if there's no
declaration for the function that expects a reference argument
has been seen by the compiler? Since it's legal not to have a
function prototype (or one that doesn't specify the arguments)
how does the compiler figure out in that case if it has to pass
a pointer or the structure itself when all it sees is
struct xxx bar;
foo(bar_ptr);
Or do you have some constraint that functions expecting refe-
rences can only be used when a full prototype has been seen?
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-06-24 23:09 +0200 |
| Message-ID | <iu2ueb$83s$1@speranza.aioe.org> |
| In reply to | #6873 |
Le 24/06/11 22:44, Jens Thoms Toerring a écrit :
> Just out of curiosity: how are things handled if there's no
> declaration for the function that expects a reference argument
> has been seen by the compiler?
lcc-win is one pass compiler. No references are assumed, and
when the prototype is seen an error occurs: redefinition
of "foo" previously defined at line such and such.
> Since it's legal not to have a
> function prototype (or one that doesn't specify the arguments)
> how does the compiler figure out in that case if it has to pass
> a pointer or the structure itself when all it sees is
>
> struct xxx bar;
> foo(bar_ptr);
>
> Or do you have some constraint that functions expecting refe-
> rences can only be used when a full prototype has been seen?
>
> Regards, Jens
Of course if this is going to work you must write a prototype!
Or pay me a special fee so that I introduce a special case
in the compiler:
if (isJensThomsToerring(currentUser) && !strcmp(functionName,"foo")) {
// pass by reference
}
:-)
[toc] | [prev] | [next] | [standalone]
| From | Joe Wright <joewwright@comcast.net> |
|---|---|
| Date | 2011-06-24 17:38 -0400 |
| Message-ID | <ruKdnSlNPq1YnpjTnZ2dnUVZ_uidnZ2d@giganews.com> |
| In reply to | #6883 |
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. -- Joe Wright "If you rob Peter to pay Paul you can depend on the support of Paul."
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2011-06-24 22:58 +0100 |
| Message-ID | <iu31ch$lte$1@dont-email.me> |
| In reply to | #6893 |
"Joe Wright" <joewwright@comcast.net> wrote in message
news:ruKdnSlNPq1YnpjTnZ2dnUVZ_uidnZ2d@giganews.com...
> 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.
I think the big thing is the implicit dereferencing. Let's say you have a
piece of code, for example:
a+=2;
and wanted to put this into a function. With references, it might look like
this:
void addtwo(int &a){
a+=2;
}
and is called as:
addtwo(a);
Notice the code in the function can be exactly the same: no "*" is needed
(plus checks for NULL) and no "&" is needed to pass the value to be
modified, so no need to write:
a=addtwo(a);
or:
addtwo(&a);
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-06-25 10:11 +1200 |
| Message-ID | <96kgcnFb9tU11@mid.individual.net> |
| In reply to | #6893 |
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, for another you don't have to clutter up your code with *& and *. The case for references in C isn't as strong as it is for C++, where references are required for operator overloading. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-06-26 17:00 -0500 |
| Message-ID | <iu86kn$att$1@dont-email.me> |
| In reply to | #6902 |
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.
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.
Please consider:
void func(int & i) { /* ... */ }
If we have some pointer ('int * ip') with a null pointer value and we do:
func(*ip);
do we not simply move the point of failure up to the caller? Whereas with:
void func(int * ip) { /* ... */ }
and:
func(ip);
if 'func' doesn't check for a null pointer value, the point of failure
is simply with the callee?
Either way, the program fails. This can't be observed at translation
time, with or without references, right?
It reminds me of "cdecl" where the caller takes responsibility for
something.
> for another you don't have to
> clutter up your code with *& and *.
>
Agreed. It's especially annoying for arrays.
void func(char (* array)[10]) {
/* ... */
... index[*array] ...
/* or */
... (*array)[index] ...
return;
}
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2011-06-26 22:55 +0100 |
| Message-ID | <iu89s5$vja$1@dont-email.me> |
| In reply to | #6987 |
"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... */ -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-06-26 18:25 -0500 |
| Message-ID | <iu8bkk$bg0$1@dont-email.me> |
| In reply to | #6990 |
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? int * ip; /* 'ip' is populated somehow */ func((assert(p), *p));
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2011-06-26 23:38 +0100 |
| Message-ID | <iu8cgo$gg0$1@dont-email.me> |
| In reply to | #6992 |
"Shao Miller" <sha0.miller@gmail.com> wrote in message news:iu8bkk$bg0$1@dont-email.me... > On 6/26/2011 4:55 PM, BartC wrote: >> 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); > 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? > > int * ip; > /* 'ip' is populated somehow */ > func((assert(p), *p)); As it seems to be implemented in lcc-win32, it appears that a reference parameter has a type distinct from a pointer type, so you can only pass a reference, and references can never be null. If that's the case, then there need be no checks for NULL, not even behind the scenes. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-06-26 19:19 -0500 |
| Message-ID | <iu8er3$1hq$1@dont-email.me> |
| In reply to | #6994 |
On 6/26/2011 5:38 PM, BartC wrote: > "Shao Miller" <sha0.miller@gmail.com> wrote in message > news:iu8bkk$bg0$1@dont-email.me... >> On 6/26/2011 4:55 PM, BartC wrote: > >>> 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); > >> 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? >> >> int * ip; >> /* 'ip' is populated somehow */ >> func((assert(p), *p)); > > As it seems to be implemented in lcc-win32, it appears that a reference > parameter has a type distinct from a pointer type, so you can only pass > a reference, and references can never be null. > > If that's the case, then there need be no checks for NULL, not even > behind the scenes. > (Of course you obviously mean "a null pointer value" by "NULL".) And there needn't be any checks for null pointer values _without_ "reference types," even behind the scenes, as far as I can tell! So I was asking about an "injected assertion" because that might be perceived as a benefit that we don't currently enjoy. Otherwise, the "referring to a valid entity" doesn't appear to be a benefit that "reference types" would have over "pointer types"; you could still call a reference-taking function with an argument that is "no entity," couldn't you?
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-06-27 01:27 +0200 |
| Message-ID | <iu8f9o$fen$1@speranza.aioe.org> |
| In reply to | #6998 |
Le 27/06/11 02:19, Shao Miller a écrit : > > And there needn't be any checks for null pointer values _without_ > "reference types," even behind the scenes, as far as I can tell! So I > was asking about an "injected assertion" because that might be perceived > as a benefit that we don't currently enjoy. Otherwise, the "referring to > a valid entity" doesn't appear to be a benefit that "reference types" > would have over "pointer types"; you could still call a reference-taking > function with an argument that is "no entity," couldn't you? 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. But I have problems with references to arrays (when trying to fix the bug you uncovered).
[toc] | [prev] | [next] | [standalone]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web