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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-07-01 20:13 -0500 |
| Message-ID | <iulnro$76o$2@dont-email.me> |
| In reply to | #7405 |
On 7/1/2011 6:58 PM, Seebs wrote: > On 2011-07-01, Keith Thompson<kst-u@mib.org> wrote: >> I find ``if (p == NULL)'' easier to read than ``if (p)'' because it >> emphasizes the fact that p is a pointer. > > See, I don't care whether p is a pointer. I care whether it's true or > not. I tend to view "p == NULL" as being in the same category as > declaring "char *ptrString" instead of "char *s". Yes, it gives more > information, but the more information is not something I really > need made explicit to work with the object, and it distracts me from > thinking at the right level. Well it's really quite amazing how diverse people are, and how different perspectives can be tolerated, and how sharing one's reasoning for one's preferences can inspire. :)
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-07-01 12:44 -0700 |
| Message-ID | <rubrum-7CA8F4.12441001072011@news.albasani.net> |
| In reply to | #7380 |
In article <iul6o2$fqd$1@speranza.aioe.org>, pacman@kosh.dhis.org (Alan Curry) wrote: > In article <rubrum-5069B7.10323130062011@news.albasani.net>, > Michael Press <rubrum@pacbell.net> wrote: > >In article <iug9bp$dfi$1@speranza.aioe.org>, > > pacman@kosh.dhis.org (Alan Curry) wrote: > >> > >> Look at these examples of concise uses of pointers as booleans, taken from 3 > >> different files in the Linux kernel: > >> > >> if (drv && drv->pm && drv->pm->prepare) > >> > >> if (p && p->detect && p->detect() > 0) > >> > >> return suspend_ops && suspend_ops->valid && suspend_ops->valid(state); > >> > >> They look so simple. You really think it would help readability to jam a > >> bunch of "!= 0" or "!= NULL" noise in there? > > > >Editors and other experts in grammar and English > >composition agree: when you write yourself into a > >corner, then recast the sentence. > > But those original "sentences" have nothing wrong with them. Brevity is > beautiful. > > > > > if ( drv != NULL > > && drv->pm != NULL > > && drv->pm->prepare != NULL) > > Nearly doubling the number of tokens can't possibly be an improvement in > readability. Do I repeat my side of the argument now? -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-07-01 15:57 -0500 |
| Message-ID | <iul8ro$3b3$1@dont-email.me> |
| In reply to | #7380 |
On 7/1/2011 2:21 PM, Alan Curry wrote:
> In article<rubrum-5069B7.10323130062011@news.albasani.net>,
> Michael Press<rubrum@pacbell.net> wrote:
>> In article<iug9bp$dfi$1@speranza.aioe.org>,
>> pacman@kosh.dhis.org (Alan Curry) wrote:
>>>
>>> Look at these examples of concise uses of pointers as booleans, taken from 3
>>> different files in the Linux kernel:
>>>
>>> if (drv&& drv->pm&& drv->pm->prepare)
>>>
>>> if (p&& p->detect&& p->detect()> 0)
>>>
>>> return suspend_ops&& suspend_ops->valid&& suspend_ops->valid(state);
>>>
>>> They look so simple. You really think it would help readability to jam a
>>> bunch of "!= 0" or "!= NULL" noise in there?
>>
>> Editors and other experts in grammar and English
>> composition agree: when you write yourself into a
>> corner, then recast the sentence.
>
> But those original "sentences" have nothing wrong with them. Brevity is
> beautiful.
>
>>
>> if ( drv != NULL
>> && drv->pm != NULL
>> && drv->pm->prepare != NULL)
>
> Nearly doubling the number of tokens can't possibly be an improvement in
> readability.
>
One pattern that I sometimes see in code is where predicates are
actually defined with either a macro or a function:
#define IS_PRIMARY_COLOUR(colour) ( \
((colour) == red) || \
((colour) == blue) || \
((colour) == yellow) \
)
And then:
if (IS_PRIMARY_COLOUR(something))
/* ... */
So:
#define IS_VALID_POINTER(ptr) (ptr)
/* ... */
if (IS_VALID_POINTER(something))
/* ... */
is perhaps more obvious while reading, by reminding you that 'something'
either is or is not a valid pointer. Whereas with:
if (!something)
/* ... */
you might not recall what 'something' is. From that perspective, I can
understand a benefit to:
if (something != NULL)
/* ... */
because like the macro, 'NULL' is a hint that 'something' is a pointer.
However, it seems a peculiarity of equality operators (and pointers)
that multiple pointer values can compare as equal with 'NULL', whereas
with other types, one is usually testing for a _particular_ value, if
I'm not mistaken. Thus I'd still sooner use the macro than the equality
operators, and constrain my use of the equality operators to comparing
particular values, where the value on the left either is or is not the
value on the right and vice versa. Comparing with 'NULL' seems more
like a classification than an identification.
But the implicit "zero/null" predicate seems pretty simple, so foo on
using the macro, despite forgetting the type of 'something'. :)
#define NONNULL(ptr) (ptr)
#define ISNULL(ptr) (!(ptr))
#define POINTS(ptr) (ptr)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2011-07-03 14:54 -0700 |
| Message-ID | <kfnei2758u9.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #7308 |
Michael Press <rubrum@pacbell.net> writes: > In article <iug9bp$dfi$1@speranza.aioe.org>, > pacman@kosh.dhis.org (Alan Curry) wrote: > >> In article <lnliwl89uq.fsf@nuthaus.mib.org>, >> Keith Thompson <kst-u@mib.org> wrote: >> >pacman@kosh.dhis.org (Alan Curry) writes: >> >> >> >> Exactly. In my mental type map, "boolean" is a very high level abstract type, >> >> and pointers are among its subclasses. >> > >> >So a "boolean" is anything that can be used as a condition, i.e., >> >anything that can be compared against 0? >> >> Basically. But "can be compared against 0" is just an under-the-hood detail. >> What makes a type boolean is that its values can be cleanly divided into >> exactly 2 subsets based on some well-chosen attribute. Null-or-nonnull is >> the only obvious way to divide pointer values into exactly 2 subsets, so >> their non-null-ness is their truthiness. >> >> Look at these examples of concise uses of pointers as booleans, taken from 3 >> different files in the Linux kernel: >> >> if (drv && drv->pm && drv->pm->prepare) >> >> if (p && p->detect && p->detect() > 0) >> >> return suspend_ops && suspend_ops->valid && suspend_ops->valid(state); >> >> They look so simple. You really think it would help readability to jam a >> bunch of "!= 0" or "!= NULL" noise in there? > > Editors and other experts in grammar and English > composition agree: when you write yourself into a > corner, then recast the sentence. > > if ( drv != NULL > && drv->pm != NULL > && drv->pm->prepare != NULL) > > if ( p != NULL > && p->detect != NULL > && p->detect() > 0) > > return suspend_ops != NULL > && suspend_ops->valid != NULL > && suspend_ops->valid(state) != NULL; These haven't been recasted, just written using a different stylistic preference -- like adding a comma after the penultimate item in a series of three or more. Regardless of one's personal preferences about style here, any programmer who doesn't immediately and easily understand the first, shorter forms of these examples either needs a C refresher course or shouldn't be programming in C.
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-07-03 20:29 -0700 |
| Message-ID | <rubrum-84871D.20293403072011@news.albasani.net> |
| In reply to | #7531 |
In article <kfnei2758u9.fsf@x-alumni2.alumni.caltech.edu>, Tim Rentsch <txr@alumni.caltech.edu> wrote: > Michael Press <rubrum@pacbell.net> writes: > > > In article <iug9bp$dfi$1@speranza.aioe.org>, > > pacman@kosh.dhis.org (Alan Curry) wrote: > > > >> In article <lnliwl89uq.fsf@nuthaus.mib.org>, > >> Keith Thompson <kst-u@mib.org> wrote: > >> >pacman@kosh.dhis.org (Alan Curry) writes: > >> >> > >> >> Exactly. In my mental type map, "boolean" is a very high level abstract type, > >> >> and pointers are among its subclasses. > >> > > >> >So a "boolean" is anything that can be used as a condition, i.e., > >> >anything that can be compared against 0? > >> > >> Basically. But "can be compared against 0" is just an under-the-hood detail. > >> What makes a type boolean is that its values can be cleanly divided into > >> exactly 2 subsets based on some well-chosen attribute. Null-or-nonnull is > >> the only obvious way to divide pointer values into exactly 2 subsets, so > >> their non-null-ness is their truthiness. > >> > >> Look at these examples of concise uses of pointers as booleans, taken from 3 > >> different files in the Linux kernel: > >> > >> if (drv && drv->pm && drv->pm->prepare) > >> > >> if (p && p->detect && p->detect() > 0) > >> > >> return suspend_ops && suspend_ops->valid && suspend_ops->valid(state); > >> > >> They look so simple. You really think it would help readability to jam a > >> bunch of "!= 0" or "!= NULL" noise in there? > > > > Editors and other experts in grammar and English > > composition agree: when you write yourself into a > > corner, then recast the sentence. > > > > if ( drv != NULL > > && drv->pm != NULL > > && drv->pm->prepare != NULL) > > > > if ( p != NULL > > && p->detect != NULL > > && p->detect() > 0) > > > > return suspend_ops != NULL > > && suspend_ops->valid != NULL > > && suspend_ops->valid(state) != NULL; > > These haven't been recasted, just written using a > different stylistic preference -- like adding a comma > after the penultimate item in a series of three or > more. > > Regardless of one's personal preferences about style > here, any programmer who doesn't immediately and easily > understand the first, shorter forms of these examples > either needs a C refresher course or shouldn't be > programming in C. Yes, they have been recast. The challenge was to readably write the predicates using "!= 0" or "!= NULL", and I met the challenge. recast ... 2. to improve the form of; reconstruct: as, he recast the sentence. -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2011-07-04 16:05 -0700 |
| Message-ID | <kfnr5653avc.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #7557 |
Michael Press <rubrum@pacbell.net> writes: > In article <kfnei2758u9.fsf@x-alumni2.alumni.caltech.edu>, > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> Michael Press <rubrum@pacbell.net> writes: >> >> > In article <iug9bp$dfi$1@speranza.aioe.org>, >> > pacman@kosh.dhis.org (Alan Curry) wrote: >> > >> >> In article <lnliwl89uq.fsf@nuthaus.mib.org>, >> >> Keith Thompson <kst-u@mib.org> wrote: >> >> >pacman@kosh.dhis.org (Alan Curry) writes: >> >> >> >> >> >> Exactly. In my mental type map, "boolean" is a very high level abstract type, >> >> >> and pointers are among its subclasses. >> >> > >> >> >So a "boolean" is anything that can be used as a condition, i.e., >> >> >anything that can be compared against 0? >> >> >> >> Basically. But "can be compared against 0" is just an under-the-hood detail. >> >> What makes a type boolean is that its values can be cleanly divided into >> >> exactly 2 subsets based on some well-chosen attribute. Null-or-nonnull is >> >> the only obvious way to divide pointer values into exactly 2 subsets, so >> >> their non-null-ness is their truthiness. >> >> >> >> Look at these examples of concise uses of pointers as booleans, taken from 3 >> >> different files in the Linux kernel: >> >> >> >> if (drv && drv->pm && drv->pm->prepare) >> >> >> >> if (p && p->detect && p->detect() > 0) >> >> >> >> return suspend_ops && suspend_ops->valid && suspend_ops->valid(state); >> >> >> >> They look so simple. You really think it would help readability to jam a >> >> bunch of "!= 0" or "!= NULL" noise in there? >> > >> > Editors and other experts in grammar and English >> > composition agree: when you write yourself into a >> > corner, then recast the sentence. >> > >> > if ( drv != NULL >> > && drv->pm != NULL >> > && drv->pm->prepare != NULL) >> > >> > if ( p != NULL >> > && p->detect != NULL >> > && p->detect() > 0) >> > >> > return suspend_ops != NULL >> > && suspend_ops->valid != NULL >> > && suspend_ops->valid(state) != NULL; >> >> These haven't been recasted, just written using a >> different stylistic preference -- like adding a comma >> after the penultimate item in a series of three or >> more. >> >> Regardless of one's personal preferences about style >> here, any programmer who doesn't immediately and easily >> understand the first, shorter forms of these examples >> either needs a C refresher course or shouldn't be >> programming in C. > > Yes, they have been recast. > The challenge was to readably write the predicates using > "!= 0" or "!= NULL", and I met the challenge. > > > recast ... > 2. to improve the form of; reconstruct: as, he recast the sentence. Apparently you think even trivial changes must amount to a change of form. That's silly. Editing is not the same as recasting -- the sets of examples above are different in detail but not in form. Replacing a tire on a bicycle, even to a different grade of tire, doesn't recast the bicycle.
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-07-05 08:32 -0700 |
| Message-ID | <rubrum-7978B9.08324905072011@news.albasani.net> |
| In reply to | #7615 |
In article <kfnr5653avc.fsf@x-alumni2.alumni.caltech.edu>, Tim Rentsch <txr@alumni.caltech.edu> wrote: > Michael Press <rubrum@pacbell.net> writes: > > > In article <kfnei2758u9.fsf@x-alumni2.alumni.caltech.edu>, > > Tim Rentsch <txr@alumni.caltech.edu> wrote: > > > >> Michael Press <rubrum@pacbell.net> writes: > >> > >> > In article <iug9bp$dfi$1@speranza.aioe.org>, > >> > pacman@kosh.dhis.org (Alan Curry) wrote: > >> > > >> >> In article <lnliwl89uq.fsf@nuthaus.mib.org>, > >> >> Keith Thompson <kst-u@mib.org> wrote: > >> >> >pacman@kosh.dhis.org (Alan Curry) writes: > >> >> >> > >> >> >> Exactly. In my mental type map, "boolean" is a very high level abstract type, > >> >> >> and pointers are among its subclasses. > >> >> > > >> >> >So a "boolean" is anything that can be used as a condition, i.e., > >> >> >anything that can be compared against 0? > >> >> > >> >> Basically. But "can be compared against 0" is just an under-the-hood detail. > >> >> What makes a type boolean is that its values can be cleanly divided into > >> >> exactly 2 subsets based on some well-chosen attribute. Null-or-nonnull is > >> >> the only obvious way to divide pointer values into exactly 2 subsets, so > >> >> their non-null-ness is their truthiness. > >> >> > >> >> Look at these examples of concise uses of pointers as booleans, taken from 3 > >> >> different files in the Linux kernel: > >> >> > >> >> if (drv && drv->pm && drv->pm->prepare) > >> >> > >> >> if (p && p->detect && p->detect() > 0) > >> >> > >> >> return suspend_ops && suspend_ops->valid && suspend_ops->valid(state); > >> >> > >> >> They look so simple. You really think it would help readability to jam a > >> >> bunch of "!= 0" or "!= NULL" noise in there? > >> > > >> > Editors and other experts in grammar and English > >> > composition agree: when you write yourself into a > >> > corner, then recast the sentence. > >> > > >> > if ( drv != NULL > >> > && drv->pm != NULL > >> > && drv->pm->prepare != NULL) > >> > > >> > if ( p != NULL > >> > && p->detect != NULL > >> > && p->detect() > 0) > >> > > >> > return suspend_ops != NULL > >> > && suspend_ops->valid != NULL > >> > && suspend_ops->valid(state) != NULL; > >> > >> These haven't been recasted, just written using a > >> different stylistic preference -- like adding a comma > >> after the penultimate item in a series of three or > >> more. > >> > >> Regardless of one's personal preferences about style > >> here, any programmer who doesn't immediately and easily > >> understand the first, shorter forms of these examples > >> either needs a C refresher course or shouldn't be > >> programming in C. > > > > Yes, they have been recast. > > The challenge was to readably write the predicates using > > "!= 0" or "!= NULL", and I met the challenge. > > > > > > recast ... > > 2. to improve the form of; reconstruct: as, he recast the sentence. > > Apparently you think even trivial changes must amount to a > change of form. That's silly. Editing is not the same as > recasting -- the sets of examples above are different in > detail but not in form. Replacing a tire on a bicycle, even > to a different grade of tire, doesn't recast the bicycle. I take it that you agree with everything else I said, or are you working your way up from the most trivial. -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | Lowell Gilbert <lgusenet@be-well.ilk.org> |
|---|---|
| Date | 2011-07-05 15:34 -0400 |
| Message-ID | <44fwmkldxz.fsf@lowell-desk.lan> |
| In reply to | #7664 |
Michael Press <rubrum@pacbell.net> writes: > In article <kfnr5653avc.fsf@x-alumni2.alumni.caltech.edu>, > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> Michael Press <rubrum@pacbell.net> writes: >> >> > In article <kfnei2758u9.fsf@x-alumni2.alumni.caltech.edu>, >> > Tim Rentsch <txr@alumni.caltech.edu> wrote: >> > >> >> Michael Press <rubrum@pacbell.net> writes: >> >> >> >> > In article <iug9bp$dfi$1@speranza.aioe.org>, >> >> > pacman@kosh.dhis.org (Alan Curry) wrote: >> >> > >> >> >> In article <lnliwl89uq.fsf@nuthaus.mib.org>, >> >> >> Keith Thompson <kst-u@mib.org> wrote: >> >> >> >pacman@kosh.dhis.org (Alan Curry) writes: >> >> >> >> >> >> >> >> Exactly. In my mental type map, "boolean" is a very high level abstract type, >> >> >> >> and pointers are among its subclasses. >> >> >> > >> >> >> >So a "boolean" is anything that can be used as a condition, i.e., >> >> >> >anything that can be compared against 0? >> >> >> >> >> >> Basically. But "can be compared against 0" is just an under-the-hood detail. >> >> >> What makes a type boolean is that its values can be cleanly divided into >> >> >> exactly 2 subsets based on some well-chosen attribute. Null-or-nonnull is >> >> >> the only obvious way to divide pointer values into exactly 2 subsets, so >> >> >> their non-null-ness is their truthiness. >> >> >> >> >> >> Look at these examples of concise uses of pointers as booleans, taken from 3 >> >> >> different files in the Linux kernel: >> >> >> >> >> >> if (drv && drv->pm && drv->pm->prepare) >> >> >> >> >> >> if (p && p->detect && p->detect() > 0) >> >> >> >> >> >> return suspend_ops && suspend_ops->valid && suspend_ops->valid(state); >> >> >> >> >> >> They look so simple. You really think it would help readability to jam a >> >> >> bunch of "!= 0" or "!= NULL" noise in there? >> >> > >> >> > Editors and other experts in grammar and English >> >> > composition agree: when you write yourself into a >> >> > corner, then recast the sentence. >> >> > >> >> > if ( drv != NULL >> >> > && drv->pm != NULL >> >> > && drv->pm->prepare != NULL) >> >> > >> >> > if ( p != NULL >> >> > && p->detect != NULL >> >> > && p->detect() > 0) >> >> > >> >> > return suspend_ops != NULL >> >> > && suspend_ops->valid != NULL >> >> > && suspend_ops->valid(state) != NULL; >> >> >> >> These haven't been recasted, just written using a >> >> different stylistic preference -- like adding a comma >> >> after the penultimate item in a series of three or >> >> more. >> >> >> >> Regardless of one's personal preferences about style >> >> here, any programmer who doesn't immediately and easily >> >> understand the first, shorter forms of these examples >> >> either needs a C refresher course or shouldn't be >> >> programming in C. >> > >> > Yes, they have been recast. >> > The challenge was to readably write the predicates using >> > "!= 0" or "!= NULL", and I met the challenge. >> > >> > >> > recast ... >> > 2. to improve the form of; reconstruct: as, he recast the sentence. >> >> Apparently you think even trivial changes must amount to a >> change of form. That's silly. Editing is not the same as >> recasting -- the sets of examples above are different in >> detail but not in form. Replacing a tire on a bicycle, even >> to a different grade of tire, doesn't recast the bicycle. > > I take it that you agree with everything else I said, > or are you working your way up from the most trivial. I believe he's using the English-language meaning of "recasting", and you are using the C-language version. But I could be wrong. -- Lowell Gilbert, embedded/networking software engineer http://be-well.ilk.org/~lowell/
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2011-07-06 15:30 -0700 |
| Message-ID | <kfnliwb11qj.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #7664 |
Michael Press <rubrum@pacbell.net> writes: > In article <kfnr5653avc.fsf@x-alumni2.alumni.caltech.edu>, > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> Michael Press <rubrum@pacbell.net> writes: >> >> > In article <kfnei2758u9.fsf@x-alumni2.alumni.caltech.edu>, >> > Tim Rentsch <txr@alumni.caltech.edu> wrote: >> > >> >> Michael Press <rubrum@pacbell.net> writes: >> >> >> >> > In article <iug9bp$dfi$1@speranza.aioe.org>, >> >> > pacman@kosh.dhis.org (Alan Curry) wrote: >> >> > >> >> >> In article <lnliwl89uq.fsf@nuthaus.mib.org>, >> >> >> Keith Thompson <kst-u@mib.org> wrote: >> >> >> >pacman@kosh.dhis.org (Alan Curry) writes: >> >> >> >> >> >> >> >> Exactly. In my mental type map, "boolean" is a very high level abstract type, >> >> >> >> and pointers are among its subclasses. >> >> >> > >> >> >> >So a "boolean" is anything that can be used as a condition, i.e., >> >> >> >anything that can be compared against 0? >> >> >> >> >> >> Basically. But "can be compared against 0" is just an under-the-hood detail. >> >> >> What makes a type boolean is that its values can be cleanly divided into >> >> >> exactly 2 subsets based on some well-chosen attribute. Null-or-nonnull is >> >> >> the only obvious way to divide pointer values into exactly 2 subsets, so >> >> >> their non-null-ness is their truthiness. >> >> >> >> >> >> Look at these examples of concise uses of pointers as booleans, taken from 3 >> >> >> different files in the Linux kernel: >> >> >> >> >> >> if (drv && drv->pm && drv->pm->prepare) >> >> >> >> >> >> if (p && p->detect && p->detect() > 0) >> >> >> >> >> >> return suspend_ops && suspend_ops->valid && suspend_ops->valid(state); >> >> >> >> >> >> They look so simple. You really think it would help readability to jam a >> >> >> bunch of "!= 0" or "!= NULL" noise in there? >> >> > >> >> > Editors and other experts in grammar and English >> >> > composition agree: when you write yourself into a >> >> > corner, then recast the sentence. >> >> > >> >> > if ( drv != NULL >> >> > && drv->pm != NULL >> >> > && drv->pm->prepare != NULL) >> >> > >> >> > if ( p != NULL >> >> > && p->detect != NULL >> >> > && p->detect() > 0) >> >> > >> >> > return suspend_ops != NULL >> >> > && suspend_ops->valid != NULL >> >> > && suspend_ops->valid(state) != NULL; >> >> >> >> These haven't been recasted, just written using a >> >> different stylistic preference -- like adding a comma >> >> after the penultimate item in a series of three or >> >> more. >> >> >> >> Regardless of one's personal preferences about style >> >> here, any programmer who doesn't immediately and easily >> >> understand the first, shorter forms of these examples >> >> either needs a C refresher course or shouldn't be >> >> programming in C. >> > >> > Yes, they have been recast. >> > The challenge was to readably write the predicates using >> > "!= 0" or "!= NULL", and I met the challenge. >> > >> > >> > recast ... >> > 2. to improve the form of; reconstruct: as, he recast the sentence. >> >> Apparently you think even trivial changes must amount to a >> change of form. That's silly. Editing is not the same as >> recasting -- the sets of examples above are different in >> detail but not in form. Replacing a tire on a bicycle, even >> to a different grade of tire, doesn't recast the bicycle. > > I take it that you agree with everything else I said, Did the revised code samples have the same semantics as the originals? Yes. Was doing that revising challenging? On a scale of 1 to 10, closer to 1 than 10. Was the revision worth doing? In the context of the discussion, it illustrated a point of view and stimulated further discussion, so it did add some value. Is the revised code an improvement over the original? I'm sure some people believe it is and other people believe it isn't. Personally I prefer the original writings in each of the three cases, but generally I try to avoid debates about style issues that are just expressions of personal preference. Were there other ways of meeting "the challenge"? I believe there are, and I think that discussion might have been more interesting (but then again it might not have). The above give my reactions to what points I now think you were, or may have been, intending to address. If there are others I don't know what they are. > or are you working your way up from the most trivial. Referring to the suggested revisions as a "recasting" seems to me like a mischaracterization. That's all I meant to comment on, because after that I didn't know what point it was you were trying to make. I didn't judge or remark on any other content because I wasn't sure what else you were trying to say.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-06-27 13:27 +1200 |
| Message-ID | <96q4l2F2dgU1@mid.individual.net> |
| In reply to | #6987 |
On 06/27/11 10:00 AM, Shao Miller wrote:
> 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.
Well to put it another way, you can't test for a null value. With a
reference parameter, the value can not be a null value. Yes you can
contrive a case where one is passed, but I'm sure we can contrive cases
for just about any C undefined behaviour.
With a pointer parameter, NULL may be a valid value.
> 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:
Well yes, that's the classic case of a function that has a pointer
parameter (or handles a pointer return) having the responsibility for
testing the value.
In C++ it is idiomatic to use pointers where NULL is a valid parameter
value (or return value) and references elsewhere.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-06-27 09:02 -0400 |
| Message-ID | <iu9v48$78v$1@dont-email.me> |
| In reply to | #7005 |
On 6/26/2011 21:27, Ian Collins wrote:
> On 06/27/11 10:00 AM, Shao Miller wrote:
>> 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.
>
> Well to put it another way, you can't test for a null value. With a
> reference parameter, the value can not be a null value. Yes you can
> contrive a case where one is passed, but I'm sure we can contrive cases
> for just about any C undefined behaviour.
>
> With a pointer parameter, NULL may be a valid value.
>
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.
>
> Well yes, that's the classic case of a function that has a pointer
> parameter (or handles a pointer return) having the responsibility for
> testing the value.
>
> In C++ it is idiomatic to use pointers where NULL is a valid parameter
> value (or return value) and references elsewhere.
>
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 | "Joel C. Salomon" <joelcsalomon@gmail.com> |
|---|---|
| Date | 2011-06-26 18:35 -0400 |
| Message-ID | <iu8c88$pu5$1@news.albasani.net> |
| In reply to | #6902 |
On 06/24/2011 06:11 PM, Ian Collins wrote: > The case for references in C isn't as strong as it is for C++, where > references are required for operator overloading. Ken Thompson implemented operator overloading for the Plan 9 C compiler without adding references; see <http://9fans.net/archive/2001/05/482>. --Joel
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-06-26 19:11 -0400 |
| Message-ID | <iu8eae$ubm$1@dont-email.me> |
| In reply to | #6993 |
On 06/26/2011 06:35 PM, Joel C. Salomon wrote: > On 06/24/2011 06:11 PM, Ian Collins wrote: >> The case for references in C isn't as strong as it is for C++, where >> references are required for operator overloading. > > Ken Thompson implemented operator overloading for the Plan 9 C compiler > without adding references; see <http://9fans.net/archive/2001/05/482>. I don't understand the context of that page well enough to figure out the answer to the following question: In a C++ context, references are needed as arguments to implement operators with side-effects (++, --, =, and compound assignment), in order to give those overloads access to the value which needs to be changed. References are needed for those operators which return lvalues: (++, --, =, compound assignment, unary *, [], ->*), in order to return something that can actually be used as an lvalue. How does Ken Thompson's implementation of operator overloading for the Plan 9 compiler deal with these issues without the use of references, or something that works very similarly? -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Joel C. Salomon" <joelcsalomon@gmail.com> |
|---|---|
| Date | 2011-06-28 00:52 -0400 |
| Message-ID | <iubmm6$g99$1@news.albasani.net> |
| In reply to | #6997 |
On 06/26/2011 07:11 PM, James Kuyper wrote: > On 06/26/2011 06:35 PM, Joel C. Salomon wrote: >> On 06/24/2011 06:11 PM, Ian Collins wrote: >>> The case for references in C isn't as strong as it is for C++, where >>> references are required for operator overloading. >> >> Ken Thompson implemented operator overloading for the Plan 9 C compiler >> without adding references; see <http://9fans.net/archive/2001/05/482>. > > References are needed for those operators which return lvalues: (++, --, > =, compound assignment, unary *, [], ->*), in order to return something > that can actually be used as an lvalue. > > How does Ken Thompson's implementation of operator overloading for the > Plan 9 compiler deal with these issues without the use of references, or > something that works very similarly? Those operator-functions take pointers (and, I think, return) pointers. --Joel
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-06-28 07:56 -0400 |
| Message-ID | <iucfhq$2vv$1@dont-email.me> |
| In reply to | #7121 |
On 06/28/2011 12:52 AM, Joel C. Salomon wrote: > On 06/26/2011 07:11 PM, James Kuyper wrote: >> On 06/26/2011 06:35 PM, Joel C. Salomon wrote: >>> On 06/24/2011 06:11 PM, Ian Collins wrote: >>>> The case for references in C isn't as strong as it is for C++, where >>>> references are required for operator overloading. >>> >>> Ken Thompson implemented operator overloading for the Plan 9 C compiler >>> without adding references; see <http://9fans.net/archive/2001/05/482>. >> >> References are needed for those operators which return lvalues: (++, --, >> =, compound assignment, unary *, [], ->*), in order to return something >> that can actually be used as an lvalue. >> >> How does Ken Thompson's implementation of operator overloading for the >> Plan 9 compiler deal with these issues without the use of references, or >> something that works very similarly? > > Those operator-functions take pointers (and, I think, return) pointers. If I understand you correctly, in order for that to work, the connection between the operator overload functions and the corresponding expressions would have to be different from that of C++. In C++, if there's applicable operator overloads, then a=b is equivalent to operator=(a,b). I have no idea whether or how Plan 9 C allows explicitly calling operator overload functions. However, if it did, and used the same syntax for doing so as in C++, the equivalent would have to be something like *operator=(&a,b). That in turn would imply that a Plan 9 C operator overload function would have less freedom than a C++ operator overload. In C++, while the normal semantics of the assignment operator imply an operator overload which takes a reference argument, and returns a reference value, it's perfectly legal to define an operator overload which does not actually do so. However, if Plan 9 C does the equivalent of *operator=(&a,b), then that freedom disappears. I won't argue that it's an important freedom, but it would certainly be a significant difference between C++ and Plan 9 C operator overloading. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-06-24 22:52 +0100 |
| Message-ID | <0.54616017405dbc848c8f.20110624225212BST.87mxh67v8z.fsf@bsb.me.uk> |
| In reply to | #6883 |
jacob navia <jacob@spamsink.net> writes:
> 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.
That's not what happened when I tried it. I got a run-time exception.
Probably my version is too old (3.8).
BTW, "one pass" does not mean you can't go back and patch up or revise
prior definitions and so on. It just means the source is read once.
Second BTW: I don't think it's an error to see a prototype for a
previously un-prototyped function (I've not checked the standard but
modulo a few details about composite types and promoted arguments I
think it's correct). Obviously, you can introduce new rules for
references since they are not standard C, but the version of lcc I have
correctly does not complain about this (although the output is wrong):
#include <stdio.h>
void f();
int main(void)
{
f(&(int){42});
return 0;
}
void f(int *ip)
{
printf("%d\n", *ip);
}
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | jt@toerring.de (Jens Thoms Toerring) |
|---|---|
| Date | 2011-06-24 23:58 +0000 |
| Message-ID | <96kmm1FjkrU1@mid.uni-berlin.de> |
| In reply to | #6883 |
jacob navia <jacob@spamsink.net> wrote:
> 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?
> Of course if this is going to work you must write a prototype!
Thanks, I see.
> 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
> }
> :-)
Sorry but not likely to happen in the near future;-)
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
[toc] | [prev] | [next] | [standalone]
| From | Tom St Denis <tom@iahu.ca> |
|---|---|
| Date | 2011-06-24 06:48 -0700 |
| Message-ID | <7eab2558-0e6c-410e-bf27-1e8eaef0faae@l18g2000yql.googlegroups.com> |
| In reply to | #6809 |
On Jun 24, 4:42 am, jacob navia <ja...@spamsink.net> 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.
>
> 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;
Simipler...
int func(int *ledata)
{
#define reflefdata (*ledata)
int a;
a = (refledata *= 4);
return a;
}
There, no more lazies.
Also no language change required. You can do things like sizeof
refledata, you can read/assign it, even take the address of it.
Tom
[toc] | [prev] | [next] | [standalone]
| From | David Resnick <lndresnick@gmail.com> |
|---|---|
| Date | 2011-06-24 07:14 -0700 |
| Message-ID | <dc7b6ef3-0e79-4ddb-9c57-29c2ef7e845a@n28g2000vbs.googlegroups.com> |
| In reply to | #6831 |
On Jun 24, 9:48 am, Tom St Denis <t...@iahu.ca> wrote:
> Simipler...
>
> int func(int *ledata)
> {
> #define reflefdata (*ledata)
> int a;
>
> a = (refledata *= 4);
> return a;
>
> }
>
> There, no more lazies.
While I'm not sold on having references in C (not clear the it is THAT
big a win), this macro crud isn't the same thing as having a ref.
Main virtue of references is self-documentation and automated function
argument semantics enforcement IMHO...
i.e. in C you might have:
/* Note: ledata absolutely CAN NOT and MUST NOT be NULL here */
int func(int *ledata)
{
if ( ledata == NULL )
{
/* do something drastic */
}
}
You can express all that extra material without the comments, checks,
whatever, with the one little '&' in the
int func( int &ledata )
Earth shattering? No, but it is sometimes nice.
-David
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-06-24 16:58 +0200 |
| Message-ID | <iu28mp$f60$2@speranza.aioe.org> |
| In reply to | #6832 |
Le 24/06/11 16:14, David Resnick a écrit :
> While I'm not sold on having references in C (not clear the it is THAT
> big a win), this macro crud isn't the same thing as having a ref.
> Main virtue of references is self-documentation and automated function
> argument semantics enforcement IMHO...
>
> i.e. in C you might have:
>
> /* Note: ledata absolutely CAN NOT and MUST NOT be NULL here */
> int func(int *ledata)
> {
> if ( ledata == NULL )
> {
> /* do something drastic */
> }
> }
>
> You can express all that extra material without the comments, checks,
> whatever, with the one little '&' in the
>
> int func( int&ledata )
>
> Earth shattering? No, but it is sometimes nice.
>
> -David
Precisely. It is not the best thing since baked bread but it is an
improvement that implies a small change in the language.
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web