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 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-06-24 14:32 -0700 |
| Message-ID | <lnr56idifs.fsf@nuthaus.mib.org> |
| In reply to | #6875 |
Shao Miller <sha0.miller@gmail.com> writes:
> On 6/24/2011 16:17, Keith Thompson wrote:
>> The "partly" refers to the fact that an initialized local const
>> pointer object, as long as the initialization isn't a null pointer,
>> will always point to the same thing, but no such guarantees can be
>> made for a pointer parameter unless you use the C99 "static" kludge.
>>
>
> I don't understand why:
>
> void foo(int * const ip);
>
> couldn't give the same guarantee, assuming the point is that 'ip' within
> the function definition for 'foo' mustn't be modified; "point to the
> same thing," even if "no thing," which is a different point.
foo(NULL);
I should have been clearer that "the same thing" refers to some object.
--
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 | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2011-06-25 09:39 +0100 |
| Message-ID | <87d3i2xq23.fsf@gmail.com> |
| In reply to | #6890 |
Keith Thompson <kst-u@mib.org> writes: > foo(NULL); > > I should have been clearer that "the same thing" refers to some object. Quite - "doesn't point to nothing" is the best thing about C++-style references.[0] (Of course, there's still the possibility of "points to thing that no longer exists", but that's a lot less common source of bugs, in my experience). Of course, the other best thing[1] is "won't end up doing a very deep copy", but that's less of a problem in C. [0] why is pass-by-reference sometimes better than pass-by-pointer? [1] why is pass-by-reference sometimes better than pass-by-value?
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-07-04 17:38 -0400 |
| Message-ID | <iutbtc$5ta$1@dont-email.me> |
| In reply to | #6916 |
On 6/25/2011 04:39, Gareth Owen wrote:
> Keith Thompson<kst-u@mib.org> writes:
>
>> foo(NULL);
>>
>> I should have been clearer that "the same thing" refers to some object.
>
> Quite - "doesn't point to nothing" is the best thing about C++-style
> references.[0] (Of course, there's still the possibility of "points to
> thing that no longer exists", but that's a lot less common source of
> bugs, in my experience).
>
I still don't get it. Three storage durations:
1. Static
foo_by_ref(bar);
foo_by_val(&bar);
It's pretty clear that the parameter for 'foo_by_*' will be/refer to an
object.
2. Automatic
foo_by_ref(bar);
foo_by_val(&bar);
It's pretty clear that the parameter for 'foo_by_*' will be/refer to an
object.
3. Allocated
foo_by_ref(*bar_ptr);
foo_by_val(bar_ptr);
This is a worry either way unless there is a run-time check for a valid
object, right?
So it seems that the former two don't have any safety advantage. It
seems that the latter warrants a check and doesn't have any safety
advantage. Please see below, too.
Also note Mr. A. Curry's observation (elsethread) that a C++ program
broke right where you would expect: As soon as the reference was
actually used; not at the call-site.
On 6/27/2011 09:02, Shao Miller wrote:
> Ah yes. But what I'm trying to understand is the benefit/savings for not having a "no entity" case to check for.
>
> /* Pointers, not checking for a null value */
> void foo(int * const ip) {
> /* Might be U. B. if 'ip' is null */
> *ip = 42;
> return;
> }
>
> int main(void) {
> int * ip = malloc(sizeof *ip);
> foo(ip);
> return 0;
> }
>
> versus:
>
> /* References, not checking for a null value */
> void bar(int & i) {
> i = 42;
> return;
> }
>
> int main(void) {
> int * ip = malloc(sizeof *ip);
> /* Might be U. B. if 'ip' is null */
> bar(*ip);
> return 0;
> }
>
> The first point of U. B. has just been shuffled up one level.
>
> But if a function receives/reads (as opposed to constructs) a pointer and takes appropriate responsibility...
>
> /* Pointers, checking for a null value */
> void foo(int * const ip) {
> /* Callers: Please ensure 'ip' is non-null */
> *ip = 42;
> return;
> }
>
> int main(void) {
> int * ip = malloc(sizeof *ip);
> if (ip)
> /* 'ip' is non-null */
> foo(ip);
> return 0;
> }
>
> and:
>
> /* References, checking for a null value */
> void bar(int & i) {
> i = 42;
> return;
> }
>
> int main(void) {
> int * ip = malloc(sizeof *ip);
> if (ip)
> /* 'ip' is non-null */
> bar(*ip);
> return 0;
> }
>
> then both are safe. Thus, I think pointers and references are quite comparable in this regard, and I don't perceive this particular advantage.
> [...]
> Aha. I see. So can a construct like the following help to catch a reference problem, assuming the program gets through the line marked "First possible U. B."?:
>
> /* References, checking for a valid reference */
> void bar(int & i) {
> /* Check for a valid reference */
> if (NULL != &i)
> i = 42;
> return;
> }
>
> int main(void) {
> int * ip = malloc(sizeof *ip);
> /* First possible U. B. */
> bar(*ip);
> return 0;
> }
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-06-24 16:33 -0400 |
| Message-ID | <iu2seb$kro$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 this context, one of the extensions that lcc-win supports is
> references, where the design is largely inspired from the C++ design.
> ...
Suppose I have the following C89:
#include <assert.h>
#include <stddef.h>
#define ELEMENTS 5
typedef double a_five_doubles[ELEMENTS];
void foo(a_five_doubles array) {
size_t i;
/*
* 'array' isn't an array, so
* these probably aren't the same size
*/
assert(
sizeof array !=
sizeof (a_five_doubles)
);
for (i = 0; i < ELEMENTS; ++i)
array[i] = 3.14159;
return;
}
int main(void) {
a_five_doubles array;
foo(array);
return 0;
}
Now suppose I have the following C89:
#include <assert.h>
#include <stddef.h>
#define ELEMENTS 5
typedef double a_five_doubles[ELEMENTS];
void foo(a_five_doubles * array) {
size_t i;
/*
* 'array' points to an array, so
* these should be the same size
*/
assert(
sizeof *array ==
sizeof (a_five_doubles)
);
for (i = 0; i < ELEMENTS; ++i)
i[*array] = 3.14159;
return;
}
int main(void) {
a_five_doubles array;
foo(&array);
return 0;
}
If lcc-win references become standard C, if I have:
#include <assert.h>
#include <stddef.h>
#define ELEMENTS 5
#define COUNTOF(array) \
(sizeof (array) / sizeof *(array))
typedef double a_five_doubles[ELEMENTS];
void foo(a_five_doubles & array) {
size_t i;
for (i = 0; i < COUNTOF(array); ++i)
array[i] = 3.14159;
return;
}
int main(void) {
a_five_doubles array;
foo(array);
return 0;
}
Does the 'for' loop execute five times? I'm guessing that C99's
6.3.2.1p3 and 6.7.5.3p7 would need to be adjusted, right? (My C++
memory for this is poor, I'm afraid, if that's relevant here.)
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-06-24 23:04 +0200 |
| Message-ID | <iu2u3s$785$1@speranza.aioe.org> |
| In reply to | #6871 |
Le 24/06/11 22:33, Shao Miller a écrit :
>
> If lcc-win references become standard C, if I have:
>
> #include <assert.h>
> #include <stddef.h>
>
> #define ELEMENTS 5
> #define COUNTOF(array) \
> (sizeof (array) / sizeof *(array))
>
> typedef double a_five_doubles[ELEMENTS];
>
> void foo(a_five_doubles & array) {
> size_t i;
>
> for (i = 0; i < COUNTOF(array); ++i)
> array[i] = 3.14159;
> return;
> }
>
> int main(void) {
> a_five_doubles array;
>
> foo(array);
> return 0;
> }
>
> Does the 'for' loop execute five times? I'm guessing that C99's
> 6.3.2.1p3 and 6.7.5.3p7 would need to be adjusted, right? (My C++ memory
> for this is poor, I'm afraid, if that's relevant here.)
That should work OK, sizeof a_five_doubles should be 40, and actually
only the address of the array is passed.
That doesn't work OK NOW because lcc-win has a bug when taking the
reference to an array. That will work OK tomorrow when I correct
that bug :-)
jacob
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2011-06-26 17:53 -0700 |
| Message-ID | <kfnfwmw9jte.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #6809 |
jacob navia <jacob@spamsink.net> writes:
> 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;
>
> [snip elaboration]
Let's look at the plusses and minuses.
Plus:
1. Reduced syntax - calls don't need '&' to take address,
uses don't need '*' to dereference, don't need 'const'
in declarations. . Frequency: common. New capability
offered: none, all these can be done currently using
small amounts of local syntax. Benefit: minor.
2. Null values avoided. Frequency: common. New capability
offered: none in the language (no additional semantics),
some in program checking (eg, like 'lint'). Benefit:
minor for program development, positive for program
verification. (See additional comments in Orthogonal.)
Orthogonal:
1. Null values avoided. I think this item more properly
belongs to program verification than programming language.
Avoiding null values doesn't add any semantics, it only
makes certain conditions impossible (presumably there
would be compiler errors). Obviously doing this has
value, but it doesn't have to be a language feature to
get the value. The proposed language feature is tied
to references, but it would be nice if a similar test
could be made for some pointer parameters. Or how about
other kinds of tests, like integer values being positive?
There are lots of useful and potentially useful kinds of
checking that could be done, but these should not be part
of the programming language, because they do not add any
language semantics, they only facilitate program checking.
A better model is either a lint-like separate checker, or
extra-linguistic progrm annotation ala __attribute__ in
gcc.
Minus:
1. Language is bigger. There is more to read and understand,
and it complicates the type system (as anyone who has
tried to read through the C++ standard can attest).
Frequency: ubiquitous for new developers, presumably low
for experienced developers. Cost: hard to quantify, but
not trivial.
2. Unobvious effects on program semantics. Because of how
non-lvalues are dealt with, calls that look similar may
have very different semantics; eg, if foo() accepts a
reference argument, 'foo( x )' and 'foo( x++ )' behave
very differently (and unobviously so as far as the call
site goes). Frequency: presumably low. Downside: for
cases where it matters, potentially large. Cost: low
frequency times large downside gives non-negligible cost.
3. Hidden side effects. Without references, when calling a
function it's immediately obvious if argument values can
be modified -- if there is an '&' (or an array is used),
then the argument might be modified, otherwise it can't
be. With references, any lvalue argument is potentially
modifiable; the only way to know is check the function
prototype. Frequency: high. Downside: additional effort
spent in program development. Cost: extra work on every
function call gives significant cost.
Summary:
In C++, the justification for references usually involves
struct's or class'es with member functions, and perhaps
the additional rules related to type conversions in the
presense of C++ 'base'/'derived' types.
In C, these factors simply aren't present. References
add essentially no additional semantic power, and bring
with them a significant burden. The one quality that
may offer value doesn't belong in the language, any
more than gcc's compiler-option style rules belong in
the language. Adding references to C gives a net result
that is overall a big minus.
If someone is interested in counting votes, I would have to
give this suggestion a thumbs down.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-06-27 17:04 +1200 |
| Message-ID | <96qhbhF2dgU4@mid.individual.net> |
| In reply to | #7004 |
On 06/27/11 12:53 PM, Tim Rentsch wrote: > jacob navia<jacob@spamsink.net> writes: >> >> 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; >> >> [snip elaboration] > > Let's look at the plusses and minuses. > > Plus: > > 1. Reduced syntax - calls don't need '&' to take address, > uses don't need '*' to dereference, don't need 'const' > in declarations. . Frequency: common. New capability > offered: none, all these can be done currently using > small amounts of local syntax. Benefit: minor. The use of const would be no different to pointer parameters. <snip> > Minus: > > 1. Language is bigger. There is more to read and understand, > and it complicates the type system (as anyone who has > tried to read through the C++ standard can attest). > Frequency: ubiquitous for new developers, presumably low > for experienced developers. Cost: hard to quantify, but > not trivial. It probably would be trivial, most other common languages use some form of pass by reference and the concept is well understood. If anything it would be easier to understand considering how tricky novices find pointers. > 2. Unobvious effects on program semantics. Because of how > non-lvalues are dealt with, calls that look similar may > have very different semantics; eg, if foo() accepts a > reference argument, 'foo( x )' and 'foo( x++ )' behave > very differently (and unobviously so as far as the call > site goes). Frequency: presumably low. Downside: for > cases where it matters, potentially large. Cost: low > frequency times large downside gives non-negligible cost. They should behave very differently at compile time! foo(x++) will fail to compile in C++ (the result of x++ is not an lvalue). > 3. Hidden side effects. Without references, when calling a > function it's immediately obvious if argument values can > be modified -- if there is an '&' (or an array is used), > then the argument might be modified, otherwise it can't > be. With references, any lvalue argument is potentially > modifiable; the only way to know is check the function > prototype. Frequency: high. Downside: additional effort > spent in program development. Cost: extra work on every > function call gives significant cost. The same applies with a pointer parameter. > Summary: > > In C++, the justification for references usually involves > struct's or class'es with member functions, and perhaps > the additional rules related to type conversions in the > presense of C++ 'base'/'derived' types. Operator overloading is probably the main reason in C++. > In C, these factors simply aren't present. References > add essentially no additional semantic power, and bring > with them a significant burden. The one quality that > may offer value doesn't belong in the language, any > more than gcc's compiler-option style rules belong in > the language. Adding references to C gives a net result > that is overall a big minus. I disagree that there is a big minus. I'd say the cost to benefit for C is about even, with the reduction in clutter tipping the balance in their favour. > If someone is interested in counting votes, I would have to > give this suggestion a thumbs down. I would consider abstaining! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2011-06-27 14:28 -0700 |
| Message-ID | <kfnboxj7yn3.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #7018 |
Ian Collins <ian-news@hotmail.com> writes:
> On 06/27/11 12:53 PM, Tim Rentsch wrote:
>> jacob navia<jacob@spamsink.net> writes:
>>>
>>> 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;
>>>
>>> [snip elaboration]
>>
>> Let's look at the plusses and minuses.
>>
>> Plus:
>>
>> 1. Reduced syntax - calls don't need '&' to take address,
>> uses don't need '*' to dereference, don't need 'const'
>> in declarations. . Frequency: common. New capability
>> offered: none, all these can be done currently using
>> small amounts of local syntax. Benefit: minor.
>
> The use of const would be no different to pointer parameters.
Not sure what you're saying here. Certainly there is a
difference between
void foo( int *p ){ ... }
and
void foo( int *const p ){ ... }
because in the second function body the pointer variable 'p'
cannot be assigned into. That question (and other similar
ones) is what I was meaning to address.
>> Minus:
>>
>> 1. Language is bigger. There is more to read and understand,
>> and it complicates the type system (as anyone who has
>> tried to read through the C++ standard can attest).
>> Frequency: ubiquitous for new developers, presumably low
>> for experienced developers. Cost: hard to quantify, but
>> not trivial.
>
> It probably would be trivial, most other common languages use some
> form of pass by reference and the concept is well understood.
Many language of 1960's-ish vintage had or have reference
parameters (and Ada does now, which is more like 1980 vintage).
But I think it's an exaggeration to say "most other common
languages" have it; with high likelihood the probabilities
run very much the other way, and reference parameters are
generally discredited in contemporary languages (with arrays
sometimes an exception to that).
Also, please note that having reference parameters is very different
from having references as a general type constructor. It's possible
to provide Ada-style parameters without having a "reference" type
constructor, and that would be a better proposal.
> If
> anything it would be easier to understand considering how tricky
> novices find pointers.
You can't be serious!
>> 2. Unobvious effects on program semantics. Because of how
>> non-lvalues are dealt with, calls that look similar may
>> have very different semantics; eg, if foo() accepts a
>> reference argument, 'foo( x )' and 'foo( x++ )' behave
>> very differently (and unobviously so as far as the call
>> site goes). Frequency: presumably low. Downside: for
>> cases where it matters, potentially large. Cost: low
>> frequency times large downside gives non-negligible cost.
>
> They should behave very differently at compile time! foo(x++) will
> fail to compile in C++ (the result of x++ is not an lvalue).
I was commenting on the language feature proposed, not on the
references that C++ has; those would be an improvement in this
regard, but my intention was to discuss just the particular proposed
feature.
>> 3. Hidden side effects. Without references, when calling a
>> function it's immediately obvious if argument values can
>> be modified -- if there is an '&' (or an array is used),
>> then the argument might be modified, otherwise it can't
>> be. With references, any lvalue argument is potentially
>> modifiable; the only way to know is check the function
>> prototype. Frequency: high. Downside: additional effort
>> spent in program development. Cost: extra work on every
>> function call gives significant cost.
>
> The same applies with a pointer parameter.
Hogwash. I know at a call site whether I'm passing a pointer,
without having to look at the prototype of the function being
called; if I'm passing a pointer then I might want to look
more carefully, but otherwise I don't have to. That condition
doesn't hold if the language has reference parameters.
>> Summary:
>>
>> In C++, the justification for references usually involves
>> struct's or class'es with member functions, and perhaps
>> the additional rules related to type conversions in the
>> presense of C++ 'base'/'derived' types.
>
> Operator overloading is probably the main reason in C++.
Pretty sure it was so struct/class instances could be thought
of as "objects", but in any case something outside of what
is relevant in C.
>> In C, these factors simply aren't present. References
>> add essentially no additional semantic power, and bring
>> with them a significant burden. The one quality that
>> may offer value doesn't belong in the language, any
>> more than gcc's compiler-option style rules belong in
>> the language. Adding references to C gives a net result
>> that is overall a big minus.
>
> I disagree that there is a big minus. I'd say the cost to benefit for
> C is about even, with the reduction in clutter tipping the balance in
> their favour.
This comment doesn't make sense. The reduction in clutter is
almost the only benefit there is in this proposal.
I might agree to a proposal that would allow a parameter with
a pointer type to be used like it was the pointed-to type (ie,
so '*' would not be necessary, and '.' could be used in place
of '->'). What is inexcusable is not requiring the '&' at
call sites, which has almost no benefit, enormous downside
risk, and costs to development both initially and on an
on-going basis.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-06-28 14:11 +1200 |
| Message-ID | <96srjcF2dgU10@mid.individual.net> |
| In reply to | #7101 |
On 06/28/11 09:28 AM, Tim Rentsch wrote:
> Ian Collins<ian-news@hotmail.com> writes:
>
>> On 06/27/11 12:53 PM, Tim Rentsch wrote:
>>> jacob navia<jacob@spamsink.net> writes:
>>>>
>>>> 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;
>>>>
>>>> [snip elaboration]
>>>
>>> Let's look at the plusses and minuses.
>>>
>>> Plus:
>>>
>>> 1. Reduced syntax - calls don't need '&' to take address,
>>> uses don't need '*' to dereference, don't need 'const'
>>> in declarations. . Frequency: common. New capability
>>> offered: none, all these can be done currently using
>>> small amounts of local syntax. Benefit: minor.
>>
>> The use of const would be no different to pointer parameters.
>
> Not sure what you're saying here. Certainly there is a
> difference between
>
> void foo( int *p ){ ... }
>
> and
>
> void foo( int *const p ){ ... }
>
> because in the second function body the pointer variable 'p'
> cannot be assigned into. That question (and other similar
> ones) is what I was meaning to address.
I see, I missed your point.
>
>>> Minus:
<snip>
>> If
>> anything it would be easier to understand considering how tricky
>> novices find pointers.
>
> You can't be serious!
Oh I am! Look at the proportion of posts here that relate to pointers.
>>> 2. Unobvious effects on program semantics. Because of how
>>> non-lvalues are dealt with, calls that look similar may
>>> have very different semantics; eg, if foo() accepts a
>>> reference argument, 'foo( x )' and 'foo( x++ )' behave
>>> very differently (and unobviously so as far as the call
>>> site goes). Frequency: presumably low. Downside: for
>>> cases where it matters, potentially large. Cost: low
>>> frequency times large downside gives non-negligible cost.
>>
>> They should behave very differently at compile time! foo(x++) will
>> fail to compile in C++ (the result of x++ is not an lvalue).
>
> I was commenting on the language feature proposed, not on the
> references that C++ has; those would be an improvement in this
> regard, but my intention was to discuss just the particular proposed
> feature.
So I see, I thought Jacob was following the C++ rules. Binding a
reference to an rvalue by creating an internal object is a fundamental
flaw in the proposal.
>>> 3. Hidden side effects. Without references, when calling a
>>> function it's immediately obvious if argument values can
>>> be modified -- if there is an '&' (or an array is used),
>>> then the argument might be modified, otherwise it can't
>>> be. With references, any lvalue argument is potentially
>>> modifiable; the only way to know is check the function
>>> prototype. Frequency: high. Downside: additional effort
>>> spent in program development. Cost: extra work on every
>>> function call gives significant cost.
>>
>> The same applies with a pointer parameter.
>
> Hogwash. I know at a call site whether I'm passing a pointer,
> without having to look at the prototype of the function being
> called; if I'm passing a pointer then I might want to look
> more carefully, but otherwise I don't have to. That condition
> doesn't hold if the language has reference parameters.
Humbug. You know you are passing a pointer, but you still have to check
to see if the function can modify the values it points to.
Anyway, my opinion has shifted to the "not a good idea in C" camp, so
I'll stop now.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2011-06-28 16:27 -0700 |
| Message-ID | <kfnr56d8rle.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #7117 |
Ian Collins <ian-news@hotmail.com> writes: > On 06/28/11 09:28 AM, Tim Rentsch wrote: >> Ian Collins<ian-news@hotmail.com> writes: >> >>> On 06/27/11 12:53 PM, Tim Rentsch wrote: >>>> jacob navia<jacob@spamsink.net> writes: [snip] > >>> If >>> anything it would be easier to understand considering how tricky >>> novices find pointers. >> >> You can't be serious! > > Oh I am! Look at the proportion of posts here that relate to pointers. I think most people don't have any problem with pointers. Most of the confusion around pointers has to do with arrays and indexing, and how those are all related. Adding references does nothing as far as arrays and indexing go -- they still need to be in the language, and still will be confusing to some people in how those relate to pointers. If anything references would muddy the waters because there would then be two fairly similar "pointer-like" concepts, adding to the confusion around how arrays work. [snip] >>>> 3. Hidden side effects. Without references, when calling a >>>> function it's immediately obvious if argument values can >>>> be modified -- if there is an '&' (or an array is used), >>>> then the argument might be modified, otherwise it can't >>>> be. With references, any lvalue argument is potentially >>>> modifiable; the only way to know is check the function >>>> prototype. Frequency: high. Downside: additional effort >>>> spent in program development. Cost: extra work on every >>>> function call gives significant cost. >>> >>> The same applies with a pointer parameter. >> >> Hogwash. I know at a call site whether I'm passing a pointer, >> without having to look at the prototype of the function being >> called; if I'm passing a pointer then I might want to look >> more carefully, but otherwise I don't have to. That condition >> doesn't hold if the language has reference parameters. > > Humbug. You know you are passing a pointer, but you still have to > check to see if the function can modify the values it points to. The key point is that when an argument is _not_ of pointer type then no check need be made. With references all arguments to all function calls would need to be checked, not just the pointer ones. > Anyway, my opinion has shifted to the "not a good idea in C" camp, so > I'll stop now. The main purpose of my comments is not so much to state a conclusion as it is to illustrate the process of how to judge proposals of this sort. I think it's important to understand on which particular points there are differences of opinion, not just that a different conclusion was reached. So even if I might internally be happy that you changed your stance on references in C, I think the most value came out of getting discussion of substance on different aspects in the cost/benefits analysis.
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-06-29 13:41 -0700 |
| Message-ID | <rubrum-B04D1B.13411029062011@news.albasani.net> |
| In reply to | #7117 |
In article <96srjcF2dgU10@mid.individual.net>, Ian Collins <ian-news@hotmail.com> wrote: > Look at the proportion of posts here that relate to pointers. Anyone who knows how a stored a stored program, digital computer works has no difficulty with pointers. A student will have trouble with pointers until he forms a model for C's abstract machine. Some never do. I think that C cannot be made easier to learn. -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-06-29 21:15 +0000 |
| Message-ID | <slrnj0n59l.hni.usenet-nospam@guild.seebs.net> |
| In reply to | #7242 |
On 2011-06-29, Michael Press <rubrum@pacbell.net> wrote: > In article <96srjcF2dgU10@mid.individual.net>, > Ian Collins <ian-news@hotmail.com> wrote: >> Look at the proportion of posts here that relate to pointers. > Anyone who knows how a stored a stored program, > digital computer works has no difficulty with pointers. *No* difficulty? I'm moderately optimistic that I have a pretty good basic understanding of how pointers work at this point, but I still trip on 'em sometimes. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-06-30 09:26 -0700 |
| Message-ID | <rubrum-0CD7A1.09264430062011@news.albasani.net> |
| In reply to | #7246 |
In article <slrnj0n59l.hni.usenet-nospam@guild.seebs.net>, Seebs <usenet-nospam@seebs.net> wrote: > On 2011-06-29, Michael Press <rubrum@pacbell.net> wrote: > > In article <96srjcF2dgU10@mid.individual.net>, > > Ian Collins <ian-news@hotmail.com> wrote: > >> Look at the proportion of posts here that relate to pointers. > > > Anyone who knows how a stored a stored program, > > digital computer works has no difficulty with pointers. > > *No* difficulty? > > I'm moderately optimistic that I have a pretty good basic understanding > of how pointers work at this point, but I still trip on 'em sometimes. There is a list of storage registers holding a number. Each storage register has an address, itself a number. The addresses are sequential: e.g. 0, 1, 2, 3, ..., N. The contents of a storage register can be read, and its contents interpreted as a machine instruction and executed. The contents of a storage register can be interpreted as an address, A, to fetch the contents of the storage register at address A. That's it. That is the only difficulty. The rest is details and thinking straight---a chronic difficulty for some, but not an inherent difficulty of pointers. Likely we are thinking of different notions when using the word "difficulty." -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-06-30 20:55 +0000 |
| Message-ID | <slrnj0pojh.2nep.usenet-nospam@guild.seebs.net> |
| In reply to | #7305 |
On 2011-06-30, Michael Press <rubrum@pacbell.net> wrote: > In article <slrnj0n59l.hni.usenet-nospam@guild.seebs.net>, > Seebs <usenet-nospam@seebs.net> wrote: >> I'm moderately optimistic that I have a pretty good basic understanding >> of how pointers work at this point, but I still trip on 'em sometimes. > There is a list of storage registers holding a number. > Each storage register has an address, itself a number. > The addresses are sequential: e.g. 0, 1, 2, 3, ..., N. This is not necessarily true of C. :) Consider the madness of segmented architectures and the like. > The contents of a storage register can be read, and its > contents interpreted as a machine instruction and > executed. > The contents of a storage register can be interpreted > as an address, A, to fetch the contents of the storage > register at address A. These are not necessarily generally true. There are many addresses which can't be fetched, and it is quite easy to have a register which can be executed but not read, or read but not executed. > That's it. That is the only difficulty. The rest is > details and thinking straight---a chronic difficulty > for some, but not an inherent difficulty of pointers. > Likely we are thinking of different notions when using > the word "difficulty." I'm thinking "I cannot with total consistency ensure that I never end up with a null pointer where I expected a valid pointer, or that I never use something after freeing it", etctera. Hmm. I haven't tried for a while, so I think I'll take this excuse to think about my Mental Map Of Pointers. In general, I tend to view objects in C as a giant pool of unconnected things, which may or may not be adjacent to each other. I do not generally have strong expectations as to which things will be adjacent to which other things, or whether anything will be adjacent to a given thing. A pointer refers to (some point within) one of these things. If you then go outside the thing it refers to, you have Lost The Game. We don't know or care what happens; don't do that. In practice, it seems that often this will reveal that two things were, in fact, adjacent. Code may or may not be things. It is not required to be things, but you can make special pointers which can point to functions rather than to things. Allocated space creates new things which are typeless until you think about them. In principle you could then reuse space for different types, but I pretty much never do. If I malloc() a bunch of floats, then I view that as a bunch of floats; I don't repurpose it for something else later, because That Would Be Crazy. I think the big divergence is simply that I don't expect pointers into different things to be comparable except in the equal/not-equal sense. I don't have any particular expectation that Things can turn into Code or vice versa; while they often can, I've used systems where attempts to do this are doomed to failure, and this appears to have significant technical advantages. I also point out that not all things in C have addresses. You can have a perfectly valid object, with a size and everything, that has no address to take. And, of course, there is at least one address which is not the address of any object. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-06-30 16:20 -0700 |
| Message-ID | <rubrum-964A10.16203330062011@news.albasani.net> |
| In reply to | #7325 |
In article <slrnj0pojh.2nep.usenet-nospam@guild.seebs.net>, Seebs <usenet-nospam@seebs.net> wrote: > On 2011-06-30, Michael Press <rubrum@pacbell.net> wrote: > > In article <slrnj0n59l.hni.usenet-nospam@guild.seebs.net>, > > Seebs <usenet-nospam@seebs.net> wrote: > >> I'm moderately optimistic that I have a pretty good basic understanding > >> of how pointers work at this point, but I still trip on 'em sometimes. > > > There is a list of storage registers holding a number. > > > Each storage register has an address, itself a number. > > > The addresses are sequential: e.g. 0, 1, 2, 3, ..., N. > > This is not necessarily true of C. :) Consider the madness > of segmented architectures and the like. > > > The contents of a storage register can be read, and its > > contents interpreted as a machine instruction and > > executed. > > > The contents of a storage register can be interpreted > > as an address, A, to fetch the contents of the storage > > register at address A. > > These are not necessarily generally true. There are many addresses > which can't be fetched, and it is quite easy to have a register which > can be executed but not read, or read but not executed. I outlined a stored program digital computer. You are talking about the C abstract machine, and that is abstracted from the spdc. The similarities are more important than the differences. [...] Are those details you list difficulties for you? They are not for me, even when I get something wrong. -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-06-30 23:45 +0000 |
| Message-ID | <slrnj0q2io.ct.usenet-nospam@guild.seebs.net> |
| In reply to | #7330 |
On 2011-06-30, Michael Press <rubrum@pacbell.net> wrote: > I outlined a stored program digital computer. > You are talking about the C abstract machine, > and that is abstracted from the spdc. The similarities > are more important than the differences. I'm not sure of this. I think the non-relation between different objects is a very big difference from the SPDC. > Are those details you list difficulties for you? > They are not for me, even when I get something wrong. Not really. The big recurring difficulties for me are just ending up with bogus pointers in one way or another -- having some spare copy of a pointer, and not realizing it should have been invalidated, stuff like that. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-07-01 07:58 -0400 |
| Message-ID | <iukcp6$50a$1@dont-email.me> |
| In reply to | #7305 |
On 06/30/2011 12:26 PM, Michael Press wrote: > In article <slrnj0n59l.hni.usenet-nospam@guild.seebs.net>, > Seebs <usenet-nospam@seebs.net> wrote: > >> On 2011-06-29, Michael Press <rubrum@pacbell.net> wrote: >>> In article <96srjcF2dgU10@mid.individual.net>, >>> Ian Collins <ian-news@hotmail.com> wrote: >>>> Look at the proportion of posts here that relate to pointers. >> >>> Anyone who knows how a stored a stored program, >>> digital computer works has no difficulty with pointers. >> >> *No* difficulty? >> >> I'm moderately optimistic that I have a pretty good basic understanding >> of how pointers work at this point, but I still trip on 'em sometimes. > > There is a list of storage registers holding a number. > > Each storage register has an address, itself a number. > > The addresses are sequential: e.g. 0, 1, 2, 3, ..., N. > > The contents of a storage register can be read, and its > contents interpreted as a machine instruction and > executed. > > The contents of a storage register can be interpreted > as an address, A, to fetch the contents of the storage > register at address A. > > That's it. That is the only difficulty. The rest is > details and thinking straight---a chronic difficulty > for some, but not an inherent difficulty of pointers. Pointer values are more than just the addresses of things; they are a higher level construct than that, and most of the problems associated with them occur at the higher level. The most important high-level feature of pointers, which is not explicitly covered by your description, is the fact that they can be invalid. They can become invalid for some purposes while remaining valid for others: 1. comparison of two pointer values for equality 2. comparison of two pointer values for relative order 3. reading through the pointer value 4. writing through the pointer value Your description of hardware addresses incorrectly implies that comparison of addresses for equality should always be safe, and that comparison of addresses for relative order should always produce consistent results; there are real-world fully-conforming implementations of C for which that's not the case for C pointer values. Uninitialized pointer objects, and pointer objects whose representation has been manipulated by means other than assignment through an lvalue of a compatible type, may have trap representations. The non-existent value of such pointer objects, and pointer values that used to point at objects whose lifetime has since ended, have undefined behavior for all four uses. Null pointer values can only be compared for equality with other pointer values; the other three uses all have undefined behavior. Comparing pointer values for relative order that do not point within (or one past the end of) the same array object (with single objects being treated as 1-element arrays) has undefined behavior. Attempting to write through a pointer value that points at an object defined as 'const' has undefined behavior; the same is true of any pointer value that points into the array corresponding to a string literal. > Likely we are thinking of different notions when using > the word "difficulty." Possibly; in my experience, most of the difficulty with C pointers comes from the necessity of avoiding the undefined behavior referred to above, an issue not even hinted at by your description of hardware addresses. With care, it's possible to avoid most such problems; but care is indeed required, and it's not always easy. To say it's "no difficulty" is to imply that such care is unnecessary. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-06-27 10:43 +0200 |
| Message-ID | <iu9fr1$biu$1@speranza.aioe.org> |
| In reply to | #7004 |
Le 27/06/11 02:53, Tim Rentsch a écrit :
> jacob navia<jacob@spamsink.net> writes:
>
>> 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;
>>
>> [snip elaboration]
>
> Let's look at the plusses and minuses.
>
> Plus:
>
> 1. Reduced syntax - calls don't need '&' to take address,
> uses don't need '*' to dereference, don't need 'const'
> in declarations. . Frequency: common. New capability
> offered: none, all these can be done currently using
> small amounts of local syntax. Benefit: minor.
>
> 2. Null values avoided. Frequency: common. New capability
> offered: none in the language (no additional semantics),
> some in program checking (eg, like 'lint'). Benefit:
> minor for program development, positive for program
> verification. (See additional comments in Orthogonal.)
>
> Orthogonal:
>
> 1. Null values avoided. I think this item more properly
> belongs to program verification than programming language.
> Avoiding null values doesn't add any semantics, it only
> makes certain conditions impossible (presumably there
> would be compiler errors). Obviously doing this has
> value, but it doesn't have to be a language feature to
> get the value. The proposed language feature is tied
> to references, but it would be nice if a similar test
> could be made for some pointer parameters. Or how about
> other kinds of tests, like integer values being positive?
> There are lots of useful and potentially useful kinds of
> checking that could be done, but these should not be part
> of the programming language, because they do not add any
> language semantics, they only facilitate program checking.
> A better model is either a lint-like separate checker, or
> extra-linguistic progrm annotation ala __attribute__ in
> gcc.
>
> Minus:
>
> 1. Language is bigger. There is more to read and understand,
> and it complicates the type system (as anyone who has
> tried to read through the C++ standard can attest).
> Frequency: ubiquitous for new developers, presumably low
> for experienced developers. Cost: hard to quantify, but
> not trivial.
>
> 2. Unobvious effects on program semantics. Because of how
> non-lvalues are dealt with, calls that look similar may
> have very different semantics; eg, if foo() accepts a
> reference argument, 'foo( x )' and 'foo( x++ )' behave
> very differently (and unobviously so as far as the call
> site goes). Frequency: presumably low. Downside: for
> cases where it matters, potentially large. Cost: low
> frequency times large downside gives non-negligible cost.
>
> 3. Hidden side effects. Without references, when calling a
> function it's immediately obvious if argument values can
> be modified -- if there is an '&' (or an array is used),
> then the argument might be modified, otherwise it can't
> be. With references, any lvalue argument is potentially
> modifiable; the only way to know is check the function
> prototype. Frequency: high. Downside: additional effort
> spent in program development. Cost: extra work on every
> function call gives significant cost.
>
> Summary:
>
> In C++, the justification for references usually involves
> struct's or class'es with member functions, and perhaps
> the additional rules related to type conversions in the
> presense of C++ 'base'/'derived' types.
>
> In C, these factors simply aren't present. References
> add essentially no additional semantic power, and bring
> with them a significant burden.
In C it would allow to avoid the famous "array decay" problem where
arrays are converted into pointers. Using references this works as expected:
#include <stdio.h>
#define ELEMENTS 5
#define COUNTOF(array) \
(sizeof (array) / sizeof *(array))
typedef double a_five_doubles[ELEMENTS];
// Change the following line to
// void foo(a_five_doubles & array)
// and it works as expected
//
void foo(a_five_doubles array)
{
size_t i;
printf("sizeof a_five_doubles=%ld\n",sizeof(array));
for (i = 0; i < COUNTOF(array); ++i) {
array[i] = 3.14159;
}
}
int main(void) {
a_five_doubles array;
for (int i = 0; i < COUNTOF(array); ++i) {
array[i] = i;
}
printf("sizeof a_five_doubles=%ld\n",sizeof(array));
foo(array);
return 0;
}
Other advantages are that you can be sure that they point always to the
same object, and that they are not NULL. This improves safety of
programs
The one quality that
> may offer value doesn't belong in the language, any
> more than gcc's compiler-option style rules belong in
> the language. Adding references to C gives a net result
> that is overall a big minus.
>
You have greatly exaggerated the completely minor problems of learning
by newcomers, and minimized the safety improvements to the language.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-06-27 08:32 -0700 |
| Message-ID | <lnfwmv9tom.fsf@nuthaus.mib.org> |
| In reply to | #7034 |
jacob navia <jacob@spamsink.net> writes:
[...]
> In C it would allow to avoid the famous "array decay" problem where
> arrays are converted into pointers. Using references this works as expected:
>
> #include <stdio.h>
>
> #define ELEMENTS 5
> #define COUNTOF(array) \
> (sizeof (array) / sizeof *(array))
>
> typedef double a_five_doubles[ELEMENTS];
>
> // Change the following line to
> // void foo(a_five_doubles & array)
> // and it works as expected
> //
> void foo(a_five_doubles array)
> {
> size_t i;
>
> printf("sizeof a_five_doubles=%ld\n",sizeof(array));
> for (i = 0; i < COUNTOF(array); ++i) {
> array[i] = 3.14159;
> }
> }
[snip]
I don't think that particular feature is all that useful. The size of
the array still has to be constant.
Unless you want to permit references to VLAs. (C++ doesn't, of course,
since C++ doesn't have VLAs.)
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2011-06-28 11:01 -0700 |
| Message-ID | <kfnzkl196oq.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #7034 |
jacob navia <jacob@spamsink.net> writes:
> Le 27/06/11 02:53, Tim Rentsch a @C3{A9}crit :
>> jacob navia<jacob@spamsink.net> writes:
>>
>>> 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;
>>>
>>> [snip elaboration]
>>
>> Let's look at the plusses and minuses.
>>
>> Plus:
>>
>> 1. Reduced syntax - calls don't need '&' to take address,
>> uses don't need '*' to dereference, don't need 'const'
>> in declarations. . Frequency: common. New capability
>> offered: none, all these can be done currently using
>> small amounts of local syntax. Benefit: minor.
>>
>> 2. Null values avoided. Frequency: common. New capability
>> offered: none in the language (no additional semantics),
>> some in program checking (eg, like 'lint'). Benefit:
>> minor for program development, positive for program
>> verification. (See additional comments in Orthogonal.)
>>
>> Orthogonal:
>>
>> 1. Null values avoided. I think this item more properly
>> belongs to program verification than programming language.
>> Avoiding null values doesn't add any semantics, it only
>> makes certain conditions impossible (presumably there
>> would be compiler errors). Obviously doing this has
>> value, but it doesn't have to be a language feature to
>> get the value. The proposed language feature is tied
>> to references, but it would be nice if a similar test
>> could be made for some pointer parameters. Or how about
>> other kinds of tests, like integer values being positive?
>> There are lots of useful and potentially useful kinds of
>> checking that could be done, but these should not be part
>> of the programming language, because they do not add any
>> language semantics, they only facilitate program checking.
>> A better model is either a lint-like separate checker, or
>> extra-linguistic progrm annotation ala __attribute__ in
>> gcc.
>>
>> Minus:
>>
>> 1. Language is bigger. There is more to read and understand,
>> and it complicates the type system (as anyone who has
>> tried to read through the C++ standard can attest).
>> Frequency: ubiquitous for new developers, presumably low
>> for experienced developers. Cost: hard to quantify, but
>> not trivial.
>>
>> 2. Unobvious effects on program semantics. Because of how
>> non-lvalues are dealt with, calls that look similar may
>> have very different semantics; eg, if foo() accepts a
>> reference argument, 'foo( x )' and 'foo( x++ )' behave
>> very differently (and unobviously so as far as the call
>> site goes). Frequency: presumably low. Downside: for
>> cases where it matters, potentially large. Cost: low
>> frequency times large downside gives non-negligible cost.
>>
>> 3. Hidden side effects. Without references, when calling a
>> function it's immediately obvious if argument values can
>> be modified -- if there is an '&' (or an array is used),
>> then the argument might be modified, otherwise it can't
>> be. With references, any lvalue argument is potentially
>> modifiable; the only way to know is check the function
>> prototype. Frequency: high. Downside: additional effort
>> spent in program development. Cost: extra work on every
>> function call gives significant cost.
>>
>> Summary:
>>
>> In C++, the justification for references usually involves
>> struct's or class'es with member functions, and perhaps
>> the additional rules related to type conversions in the
>> presense of C++ 'base'/'derived' types.
>>
>> In C, these factors simply aren't present. References
>> add essentially no additional semantic power, and bring
>> with them a significant burden.
>
> In C it would allow to avoid the famous "array decay" problem where
> arrays are converted into pointers. Using references this works as expected:
>
> [snip code example]
The same thing can be done with a pointer to array.
> Other advantages are that you can be sure that they point always
> to the same object,
The same thing is true of a pointer of type 'T *const'.
> and that they are not NULL. This improves safety of
> programs
I agree that preventing dereferences of null pointers can
improve program safety, but there are other and better
ways to do that than changing the language definition.
>> The one quality that
>> may offer value doesn't belong in the language, any
>> more than gcc's compiler-option style rules belong in
>> the language. Adding references to C gives a net result
>> that is overall a big minus.
>>
>
> You have greatly exaggerated the completely minor problems of learning
> by newcomers,
I don't see any reason to expect adding references to C would make
learning the language easier, and in fact quite the contrary - if
the language is bigger it's natural to expect that learning the
language will be harder and take longer.
Also, your listings of positive points disregards the potential
risks and negatives, which in my judgment (as outlined above)
clearly outweigh the positives.
> and minimized the safety improvements to the language.
I quite appreciate the value of safer programs; I simply have
a different judgment about whether this aspect belongs in the
language definition or is better done using other tools.
More generally, if you want to be successful in advocating
changes to the C language, it's important to hear and appreciate
the opinions and judgments of other people, even when -- or
especially when -- they don't agree with your own.
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web