Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #6809 > unrolled thread

References in C

Back to article view | Back to comp.lang.c

Contents

  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 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7  Next page →

#6996

On 6/26/2011 5:23 PM, Keith Thompson wrote:
> Shao Miller<sha0.miller@gmail.com>  writes:
>> On 6/24/2011 5:11 PM, Ian Collins wrote:
>>> On 06/25/11 09:38 AM, Joe Wright wrote:
>>>> On 6/24/2011 17:09, jacob navia wrote:
>>>>
>>>> [ Snipping everything }
>>>>
>>>> What advantage does C++ reference have? None say I. Pass&var and accept
>>>> *var and all is solved simply. Tell me where I'm wrong.
>>>
>>> For one, you don't have to test for NULL,
>>
>> (By which you obviously mean a null pointer value.  I don't use 'if (p
>> == NULL)' but 'if (!p)'.)
>
> I prefer to be more explicit, but your mileage obviously varies.
>

Yes, it does. :)

We can divide the set of pointer values in three subsets, perhaps:
  1. null pointer values
  2. traps
  3. valid pointer values

I tend to use the relational and equality operators to compare a pointer 
value with those members of subset #3.  'if' by itself (and '!' by 
itself) can "naturally" distinguish between members of #1 and #3, so I 
save some typing.

There's also a bit of C89 rationale, where if 'NULL' is '(void *) 0', 
then 'if (func_ptr == NULL)' might be comparing a pointer-to-function 
with a pointer-to-incomplete, which doesn't seem quite right.  I'd 
sooner do 'if (func_ptr == 0)' than do 'if (func_ptr == NULL)'.

>> But I still don't fully perceive this particular benefit, here.
>>
>> For "static" and "automatic" objects, if you pass '&x', there can be
>> little doubt that the called function gets a valid "reference" to an
>> object.  This can be observed at translation time.
>>
>> For "allocated" objects, if we check for allocation success (not
>> everyone does, of course), then there should be no doubt about having a
>> valid object reference.
>
> Sure, the *caller* should know whether a pointer value it's passing is,
> or might be, or definitely isn't a null pointer.  But the function
> itself doesn't.
>
> Sometimes a null pointer is a valid value.  Sometimes it isn't.
> Reference parameters (in languages that support them) are for the
> latter case.

Sure.  But:

   void func(int & i) {
       ++i;
       return;
     }

   int main(void) {
       int * ip = NULL;
       func(*ip);
       return 0;
     }

is still a problem, isn't it?  It's just that the undefined behaviour 
occurs in 'main' rather than in 'func', if 'func' had taken and worked 
with a pointer.

[toc] | [prev] | [next] | [standalone]

#7010

Shao Miller <sha0.miller@gmail.com> writes:
> On 6/26/2011 5:23 PM, Keith Thompson wrote:
>> Shao Miller<sha0.miller@gmail.com>  writes:
>>> On 6/24/2011 5:11 PM, Ian Collins wrote:
>>>> On 06/25/11 09:38 AM, Joe Wright wrote:
>>>>> On 6/24/2011 17:09, jacob navia wrote:
>>>>>
>>>>> [ Snipping everything }
>>>>>
>>>>> What advantage does C++ reference have? None say I. Pass&var and accept
>>>>> *var and all is solved simply. Tell me where I'm wrong.
>>>>
>>>> For one, you don't have to test for NULL,
>>>
>>> (By which you obviously mean a null pointer value.  I don't use 'if (p
>>> == NULL)' but 'if (!p)'.)
>>
>> I prefer to be more explicit, but your mileage obviously varies.
>
> Yes, it does. :)
>
> We can divide the set of pointer values in three subsets, perhaps:
>   1. null pointer values
>   2. traps
>   3. valid pointer values
>
> I tend to use the relational and equality operators to compare a pointer 
> value with those members of subset #3.  'if' by itself (and '!' by 
> itself) can "naturally" distinguish between members of #1 and #3, so I 
> save some typing.

I'm not going to try to change your mind, but my own preference is to
apply "if" and "!" only to value that are logically boolean, in other
words, where there's a false value and one or more true values, with no
meaningful distinction among the true values.  The result if isprint(),
for example, qualifies; the result of strcmp() does not.

> There's also a bit of C89 rationale, where if 'NULL' is '(void *) 0', 
> then 'if (func_ptr == NULL)' might be comparing a pointer-to-function 
> with a pointer-to-incomplete, which doesn't seem quite right.  I'd 
> sooner do 'if (func_ptr == 0)' than do 'if (func_ptr == NULL)'.

Ah, but it absolutely is "quite right".  NULL is a null pointer
constant, which means it can be compared to a value of *any*
pointer type.  It's the compiler's job to worry about how it's
defined, and about making it work correctly.

[...]
>> Sometimes a null pointer is a valid value.  Sometimes it isn't.
>> Reference parameters (in languages that support them) are for the
>> latter case.
>
> Sure.  But:
>
>    void func(int & i) {
>        ++i;
>        return;
>      }
>
>    int main(void) {
>        int * ip = NULL;
>        func(*ip);
>        return 0;
>      }
>
> is still a problem, isn't it?  It's just that the undefined behaviour 
> occurs in 'main' rather than in 'func', if 'func' had taken and worked 
> with a pointer.

Of course it's a problem.  Using references doesn't prevent problems
with null pointers; nobody ever claimed that it would.  It's mostly a
notational convenience.

-- 
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]

#7053

On 6/26/2011 22:21, Keith Thompson wrote:
> Shao Miller<sha0.miller@gmail.com>  writes:
>> On 6/26/2011 5:23 PM, Keith Thompson wrote:
>>> Shao Miller<sha0.miller@gmail.com>   writes:
>>>> On 6/24/2011 5:11 PM, Ian Collins wrote:
>>>>> On 06/25/11 09:38 AM, Joe Wright wrote:
>>>>>> On 6/24/2011 17:09, jacob navia wrote:
>>>>>>
>>>>>> [ Snipping everything }
>>>>>>
>>>>>> What advantage does C++ reference have? None say I. Pass&var and accept
>>>>>> *var and all is solved simply. Tell me where I'm wrong.
>>>>>
>>>>> For one, you don't have to test for NULL,
>>>>
>>>> (By which you obviously mean a null pointer value.  I don't use 'if (p
>>>> == NULL)' but 'if (!p)'.)
>>>
>>> I prefer to be more explicit, but your mileage obviously varies.
>>
>> Yes, it does. :)
>>
>> We can divide the set of pointer values in three subsets, perhaps:
>>    1. null pointer values
>>    2. traps
>>    3. valid pointer values
>>
>> I tend to use the relational and equality operators to compare a pointer
>> value with those members of subset #3.  'if' by itself (and '!' by
>> itself) can "naturally" distinguish between members of #1 and #3, so I
>> save some typing.
>
> I'm not going to try to change your mind, but my own preference is to
> apply "if" and "!" only to value that are logically boolean, in other
> words, where there's a false value and one or more true values, with no
> meaningful distinction among the true values.  The result if isprint(),
> for example, qualifies; the result of strcmp() does not.
>

Aha!  That makes perfect sense.  And indeed the "natural" predicate I 
consider is "is a valid pointer."  Perhaps something like:

   enum colour {
       black,
       red,
       more_red,
       still_more_red,
       /* ... */
       yellow,
       /* ... */
       blue,
       /* ... */
     };
   #define IS_COLOUR(subject) (subject)

>> There's also a bit of C89 rationale, where if 'NULL' is '(void *) 0',
>> then 'if (func_ptr == NULL)' might be comparing a pointer-to-function
>> with a pointer-to-incomplete, which doesn't seem quite right.  I'd
>> sooner do 'if (func_ptr == 0)' than do 'if (func_ptr == NULL)'.
>
> Ah, but it absolutely is "quite right".  NULL is a null pointer
> constant, which means it can be compared to a value of *any*
> pointer type.  It's the compiler's job to worry about how it's
> defined, and about making it work correctly.
>

Excellent point.  I must discard that rationale entirely.  Thanks.

> [...]
>>> Sometimes a null pointer is a valid value.  Sometimes it isn't.
>>> Reference parameters (in languages that support them) are for the
>>> latter case.
>>
>> Sure.  But:
>>
>>     void func(int&  i) {
>>         ++i;
>>         return;
>>       }
>>
>>     int main(void) {
>>         int * ip = NULL;
>>         func(*ip);
>>         return 0;
>>       }
>>
>> is still a problem, isn't it?  It's just that the undefined behaviour
>> occurs in 'main' rather than in 'func', if 'func' had taken and worked
>> with a pointer.
>
> Of course it's a problem.  Using references doesn't prevent problems
> with null pointers; nobody ever claimed that it would.  It's mostly a
> notational convenience.
>

Notational convenience is not disputed.  I thought we were discussing a 
very particular point here: "For one, you don't have to test for NULL."

These "references" certainly seem prettier than:

   void func(int * const ip) {
       #ifdef i
       #undef i
       #endif
       #define i (*ip)
       /* Work with 'i' */
       i = 42;
       {
           /* Inner scope.  Uh oh... */
           enum { i = 5 };
         }
       return;
       #undef i
     }

   int main(void) {
       int i;
       func(&i);
       return 0;
     }

[toc] | [prev] | [next] | [standalone]

#7075

Shao Miller <sha0.miller@gmail.com> writes:
> On 6/26/2011 22:21, Keith Thompson wrote:
>> Shao Miller<sha0.miller@gmail.com>  writes:
[...]
>>> I tend to use the relational and equality operators to compare a pointer
>>> value with those members of subset #3.  'if' by itself (and '!' by
>>> itself) can "naturally" distinguish between members of #1 and #3, so I
>>> save some typing.
>>
>> I'm not going to try to change your mind, but my own preference is to
>> apply "if" and "!" only to value that are logically boolean, in other
>> words, where there's a false value and one or more true values, with no
>> meaningful distinction among the true values.  The result if isprint(),
>> for example, qualifies; the result of strcmp() does not.
>>
>
> Aha!  That makes perfect sense.  And indeed the "natural" predicate I 
> consider is "is a valid pointer."  Perhaps something like:
>
>    enum colour {
>        black,
>        red,
>        more_red,
>        still_more_red,
>        /* ... */
>        yellow,
>        /* ... */
>        blue,
>        /* ... */
>      };
>    #define IS_COLOUR(subject) (subject)

And for a pointer value p, the way to express the predicate "is a
valid pointer" is "p != NULL".  The expression "p" is another way
to express the same predicate, but it's not *just* a predicate;
it also gives you the value of the pointer, if you care to use it.

If you choose to omit the "!= NULL", I won't say you're wrong
(because you're not); it's just not the way I do it.

[...]

>>>> Sometimes a null pointer is a valid value.  Sometimes it isn't.
>>>> Reference parameters (in languages that support them) are for the
>>>> latter case.
>>>
>>> Sure.  But:
>>>
>>>     void func(int&  i) {
>>>         ++i;
>>>         return;
>>>       }
>>>
>>>     int main(void) {
>>>         int * ip = NULL;
>>>         func(*ip);
>>>         return 0;
>>>       }
>>>
>>> is still a problem, isn't it?  It's just that the undefined behaviour
>>> occurs in 'main' rather than in 'func', if 'func' had taken and worked
>>> with a pointer.
>>
>> Of course it's a problem.  Using references doesn't prevent problems
>> with null pointers; nobody ever claimed that it would.  It's mostly a
>> notational convenience.
>>
>
> Notational convenience is not disputed.  I thought we were discussing a 
> very particular point here: "For one, you don't have to test for NULL."

In the same sense that you don't have to worry about a
const-qualified object changing its value.  It *can*, if you program
does something with undefined behavior, but then the problem is
somewhere else in your code -- and there's a chance that your
compiler or other tool can catch the problem.

[...]

-- 
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]

#7111

In article <iua1bs$nkp$1@dont-email.me>,
Shao Miller  <sha0.miller@gmail.com> wrote:
>On 6/26/2011 22:21, Keith Thompson wrote:
>>
>> I'm not going to try to change your mind, but my own preference is to
>> apply "if" and "!" only to value that are logically boolean, in other
>> words, where there's a false value and one or more true values, with no
>> meaningful distinction among the true values.  The result if isprint(),
>> for example, qualifies; the result of strcmp() does not.
>>
>
>Aha!  That makes perfect sense.  And indeed the "natural" predicate I 
>consider is "is a valid pointer."  Perhaps something like:

Exactly. In my mental type map, "boolean" is a very high level abstract type,
and pointers are among its subclasses.

>
>These "references" certainly seem prettier than:
>
>   void func(int * const ip) {
>       #ifdef i
>       #undef i
>       #endif
>       #define i (*ip)
>       /* Work with 'i' */
>       i = 42;
>       {
>           /* Inner scope.  Uh oh... */
>           enum { i = 5 };
>         }
>       return;
>       #undef i
>     }

The #ifdef portion is unnecessary and possibly even harmful. If you have a
conflicting definition of the identifier "i" you should be happy to find out
about it as soon as possible. undefining it just covers up a problem, which
may show up later anyway since you don't get back the original definition
after the end of the function.

So there really should be only 2 additional "ugly" lines, the #define and the
last #undef.

-- 
Alan Curry

[toc] | [prev] | [next] | [standalone]

#7188

pacman@kosh.dhis.org (Alan Curry) writes:
> In article <iua1bs$nkp$1@dont-email.me>,
> Shao Miller  <sha0.miller@gmail.com> wrote:
>>On 6/26/2011 22:21, Keith Thompson wrote:
>>>
>>> I'm not going to try to change your mind, but my own preference is to
>>> apply "if" and "!" only to value that are logically boolean, in other
>>> words, where there's a false value and one or more true values, with no
>>> meaningful distinction among the true values.  The result if isprint(),
>>> for example, qualifies; the result of strcmp() does not.
>>>
>>
>>Aha!  That makes perfect sense.  And indeed the "natural" predicate I 
>>consider is "is a valid pointer."  Perhaps something like:
>
> 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?

Ok.  I'll just say that your mental map differs from mine.

[...]

-- 
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]

#7223

On 2011-06-29, 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?

Pretty close, for me.  Well, mine's influenced by Lua and Ruby, both of
which consider integer 0 (and empty strings, for that matter) to be
logically-true.  A boolean is any thing which has true and false states
as measured by an if statement.  In C, that means "can be compared against
0".

I find
	if (p)
MUCH clearer to read than
	if (p != NULL)
in most cases.  The former has a very clear predicate; a pointer, which may
or may not point.  The latter has two objects and I have to think about
them.  I've pretty much internalized the notion that a pointer can be
reasonably interpreted as a yes/no question.

	restaurant *where_i_want_to_go_for_lunch;

	if (where_i_want_to_go_for_lunch) {
		...
	}

Basically, I tend to perceive if (p) as "is there a..." and *p as "what is
the..."

-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]

#7231

Seebs <usenet-nospam@seebs.net> writes:

> On 2011-06-29, 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?
>
> Pretty close, for me.  Well, mine's influenced by Lua and Ruby, both of
> which consider integer 0 (and empty strings, for that matter) to be
> logically-true.  A boolean is any thing which has true and false states
> as measured by an if statement.  In C, that means "can be compared against
> 0".
>
> I find
> 	if (p)
> MUCH clearer to read than
> 	if (p != NULL)
> in most cases.  The former has a very clear predicate; a pointer, which may
> or may not point.  The latter has two objects and I have to think about
> them.  I've pretty much internalized the notion that a pointer can be
> reasonably interpreted as a yes/no question.
>
> 	restaurant *where_i_want_to_go_for_lunch;
>
> 	if (where_i_want_to_go_for_lunch) {
> 		...
> 	}
>
> Basically, I tend to perceive if (p) as "is there a..." and *p as "what is
> the..."

I'm pretty sure I've settled on if(p) and (if p == NULL).  It might be
illogical, but in one case you're saying "is p 'anything valid'" and in
the second "is p the special invalid case".  Both positive tests, and I
certainly find positive tests easier to read (I really quite like
"unless" for, I think, the same reason).
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

[toc] | [prev] | [next] | [standalone]

#7254

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?

On the other hand, floating point values aren't so clearly good for boolean
usage. You can compare them against 0, which means you can use them as
conditions, but you'll be disappointed when some theoretically false value is
actually 1e-20 and therefore true.

But maybe you have a variable that always holds a multiple of 0.5 so it can't
go near 0 without being 0. In that case I wouldn't say it's necessarily bad
to abbreviate
  if(var != 0.0)
like this:
  if(var)

-- 
Alan Curry

[toc] | [prev] | [next] | [standalone]

#7255

pacman@kosh.dhis.org (Alan Curry) writes:
> 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?

Yes.

[...]

-- 
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]

#7477

Keith Thompson <kst-u@mib.org> writes:
> pacman@kosh.dhis.org (Alan Curry) writes:
> > 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?
> 
> Yes.

Well, I'd be the first to nack your patches were you to try and 
help readability in Nokia's meego-by-name-only linux kernel!

But these are matters of style and taste, so it's not that you're
wrong, just at odds with the spartan choices linux (if it may be 
anthropomorphised) generally prefers. A quick git grep shows that
this preference is a weak one, there's plenty of more verbose
conditions in the kernel.

Phil
-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle." -- Matthew Vernon

[toc] | [prev] | [next] | [standalone]

#7480

On Jul 2, 3:31 pm, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
wrote:
> Keith Thompson <ks...@mib.org> writes:
> > pac...@kosh.dhis.org (Alan Curry) writes:
> > > 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?
>
> > Yes.
>
> Well, I'd be the first to nack your patches were you to try and
> help readability in Nokia's meego-by-name-only linux kernel!
>
> But these are matters of style and taste, so it's not that you're
> wrong, just at odds with the spartan choices linux (if it may be
> anthropomorphised) generally prefers. A quick git grep shows that
> this preference is a weak one, there's plenty of more verbose
> conditions in the kernel.
>

And this can also lead to following creative abuse..

while(the_pope_is_gay) {
  /* do something really unholy */
}

[toc] | [prev] | [next] | [standalone]

#7256

On 6/29/2011 5:35 PM, Alan Curry wrote:
> is their truthiness.
>

I laughed out loud. :)

[toc] | [prev] | [next] | [standalone]

#7308

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;

-- 
Michael Press

[toc] | [prev] | [next] | [standalone]

#7345

"Michael Press" <rubrum@pacbell.net> ha scritto nel messaggio
news:rubrum-5069B7.10323130062011@news.albasani.net...
> In article <iug9bp$dfi$1@speranza.aioe.org>,
> pacman@kosh.dhis.org (Alan Curry) wrote:
>
>>         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;

 if(drv!=0 && drv->pm!=0 && drv->pm->prepare!=0)

 if (p!=0 && p->detect!=0 && p->detect()>0)

 return  suspend_ops!=0&&suspend_ops->valid!=0
                       &&suspend_ops->valid(state)!=0;

[toc] | [prev] | [next] | [standalone]

#7380

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.

-- 
Alan Curry

[toc] | [prev] | [next] | [standalone]

#7381

pacman@kosh.dhis.org (Alan Curry) writes:
[...]
> Nearly doubling the number of tokens can't possibly be an improvement in
> readability.

Seriously?

-- 
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]

#7382

In article <ln7h817q7p.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
>pacman@kosh.dhis.org (Alan Curry) writes:
>[...]
>> Nearly doubling the number of tokens can't possibly be an improvement in
>> readability.
>
>Seriously?

You read long texts faster than short ones?

-- 
Alan Curry

[toc] | [prev] | [next] | [standalone]

#7388

pacman@kosh.dhis.org (Alan Curry) writes:
> In article <ln7h817q7p.fsf@nuthaus.mib.org>,
> Keith Thompson  <kst-u@mib.org> wrote:
>>pacman@kosh.dhis.org (Alan Curry) writes:
>>[...]
>>> Nearly doubling the number of tokens can't possibly be an improvement in
>>> readability.
>>
>>Seriously?
>
> You read long texts faster than short ones?

Spd s nt th nl cncrn. [*]

Readability is not purely a function of either length or speed.
I could probably read a one-page C program faster than I could read
a one-line APL program, even if I knew both languages equally well
(I don't).

Is the readability of a C program improved by removing all comments and
shortening all identifiers to 1 or 2 characters?  (Ok, strictly speaking
neither of those changes the number of tokens, but it's the same general
idea.)

I like to have visual cues that make it clearer what's going on.
Often those visual cues are in the form of extra tokens.
``(x ^ y) | z'' is easier (for me) to read than ``x ^ y | z'',
because the former doesn't force me to look up or remember the
relative precedence of bitwise inclusive and exclusive OR.

I find ``if (p == NULL)'' easier to read than ``if (p)'' because it
emphasizes the fact that p is a pointer.

If you find ``if (p)'' clearer, that's fine.  I'm not trying
to change your mind, just saying that readability is not always
inversely related to the number of tokens.

(Unless, of course, p is actually a character.  8-)})

[*] Speed is not the only concern.

-- 
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]

#7405

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.

-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]

Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7  Next page →

Back to top | Article view | comp.lang.c

csiph-web