Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #386797 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2024-07-06 08:49 -0300 |
| Last post | 2024-08-25 23:45 -0400 |
| Articles | 20 on this page of 135 — 19 participants |
Back to article view | Back to comp.lang.c
question about nullptr Thiago Adams <thiago.adams@gmail.com> - 2024-07-06 08:49 -0300
Re: question about nullptr Bonita Montero <Bonita.Montero@gmail.com> - 2024-07-06 14:13 +0200
Re: question about nullptr John McCue <jmccue@neutron.jmcunx.com> - 2024-07-06 12:33 +0000
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-06 12:54 +0000
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-06 15:07 +0200
Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-06 14:04 +0000
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-06 16:42 +0200
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-06 16:45 +0200
Re: question about nullptr Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-07-06 10:50 -0700
Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-06 23:04 +0000
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-06 20:06 -0700
Re: question about nullptr bart <bc@freeuk.com> - 2024-07-06 19:20 +0100
Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-06 23:09 +0000
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 16:31 -0700
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-06 13:23 -0700
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-06 13:28 -0700
Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-07 08:01 +0000
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-08 22:08 -0700
Re: question about nullptr Richard Damon <richard@damon-family.org> - 2024-07-06 17:04 -0400
Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-06 23:10 +0000
Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-06 23:03 +0000
Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-06 21:44 -0400
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 19:29 -0700
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-07 12:53 -0700
Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-07 08:03 +0000
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-06 23:14 +0100
Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-06 23:13 +0000
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-06 20:10 -0700
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-07 08:46 +0000
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-07 19:59 +0100
Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-07 19:40 +0000
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-07 15:17 -0700
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-08 20:11 +0200
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-08 13:32 -0700
Re: question about nullptr Michael S <already5chosen@yahoo.com> - 2024-07-08 22:28 +0300
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-08 15:23 -0700
Re: question about nullptr Michael S <already5chosen@yahoo.com> - 2024-07-09 10:48 +0300
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-09 04:32 -0700
Re: question about nullptr Thiago Adams <thiago.adams@gmail.com> - 2024-07-09 09:10 -0300
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-09 07:52 -0700
Re: question about nullptr Thiago Adams <thiago.adams@gmail.com> - 2024-07-09 13:16 -0300
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-09 14:22 -0700
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-09 22:25 +0000
Re: question about nullptr Thiago Adams <thiago.adams@gmail.com> - 2024-07-10 08:50 -0300
Re: question about nullptr Michael S <already5chosen@yahoo.com> - 2024-07-09 15:50 +0300
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-09 07:50 -0700
Re: question about nullptr David Brown <david.brown@hesbynett.no> - 2024-07-09 18:19 +0200
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-09 02:49 +0000
Re: question about nullptr Michael S <already5chosen@yahoo.com> - 2024-07-09 11:00 +0300
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-09 08:21 +0000
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-09 03:57 -0700
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-08 20:17 -0700
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-08 21:01 -0700
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-08 22:06 -0700
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-10 07:51 -0700
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-10 14:23 -0700
Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-10 18:50 -0400
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 17:42 -0700
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-12 18:33 -0700
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 18:10 -0700
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-12 18:44 -0700
Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-08 14:09 +0000
Re: question about nullptr Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-07-08 21:45 -0700
Re: question about nullptr Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-07-08 21:49 -0700
Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-11 02:42 +0000
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-08 22:58 -0700
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-10 07:36 -0700
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-10 14:15 -0700
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-11 20:52 -0700
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-08 20:07 +0200
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-08 23:55 +0100
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-10 17:28 +0200
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-11 00:25 +0100
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-12 14:08 +0200
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-13 00:59 +0100
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-13 04:01 +0200
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-15 00:00 +0100
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-13 04:18 +0200
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-17 09:26 -0700
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-08 12:29 +0200
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-08 17:23 +0100
Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-08 11:03 -0400
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-09 02:45 +0000
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-08 11:08 +0200
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-08 11:18 +0100
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-09 02:32 +0000
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-08 22:02 -0700
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-09 10:21 +0100
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-10 17:32 -0700
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-11 02:12 +0100
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-10 18:41 -0700
Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-11 02:38 +0000
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-12 14:11 +0200
Re: question about nullptr Richard Damon <richard@damon-family.org> - 2024-07-08 07:18 -0400
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-08 07:19 +0000
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-08 00:42 +0100
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-06 20:36 -0700
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-06 22:11 +0000
Re: question about nullptr bart <bc@freeuk.com> - 2024-07-06 14:51 +0100
Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-07 04:55 +0000
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-07 00:04 -0700
Re: question about nullptr bart <bc@freeuk.com> - 2024-07-07 18:40 +0100
Re: question about nullptr Richard Harnden <richard.nospam@gmail.invalid> - 2024-07-12 14:19 +0100
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-12 21:52 +0000
Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-12 22:27 +0000
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-12 23:28 +0000
Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-13 00:10 +0000
Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-12 20:28 -0400
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-12 17:30 -0700
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-13 17:21 -0700
Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-15 22:51 +0000
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-15 16:32 -0700
Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-15 19:49 -0400
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-15 18:22 -0700
Re: question about nullptr dave_thompson_2@comcast.net - 2024-08-25 16:55 -0400
Re: question about nullptr Richard Damon <richard@damon-family.org> - 2024-08-25 17:09 -0400
Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-25 23:46 -0400
Re: question about nullptr Richard Damon <richard@damon-family.org> - 2024-07-06 10:39 -0400
Re: question about nullptr David Brown <david.brown@hesbynett.no> - 2024-07-06 18:57 +0200
Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-07 08:00 +0000
Re: question about nullptr David Brown <david.brown@hesbynett.no> - 2024-07-07 12:07 +0200
Re: question about nullptr Thiago Adams <thiago.adams@gmail.com> - 2024-07-07 08:40 -0300
Re: question about nullptr Richard Harnden <richard.nospam@gmail.invalid> - 2024-07-09 06:42 +0100
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-08 23:17 -0700
Re: question about nullptr Richard Harnden <richard.nospam@gmail.invalid> - 2024-07-09 08:02 +0100
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-09 00:12 -0700
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-09 11:14 +0100
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-09 13:24 -0700
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-09 13:28 -0700
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-10 14:27 +0100
Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-10 11:09 -0400
Re: question about nullptr dave_thompson_2@comcast.net - 2024-08-25 16:56 -0400
Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-25 20:48 -0400
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-25 18:18 -0700
Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-25 23:45 -0400
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-08-12 18:44 -0700 |
| Message-ID | <87ikw5gpsn.fsf@nosuchdomain.example.com> |
| In reply to | #387534 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>> [...]
>>>>> This posting has inspired me to try using (long)0.0
>>>>> whenever a null pointer constant is needed. As for
>>>>> example
>>>>>
>>>>> (void*){ (long)0.0 }
>>>>>
>>>>> as an argument to a variadic function where a pointer
>>>>> is expected.
>>>>
>>>> But surely ((void*)('/'/'/'-'/'/'/')) is more elegant.
>>>
>>> Surely not. Furthermore the form I showed has a point,
>>> whereas this example is roughly the equivalent of a
>>> first grade knock-knock joke.
>>
>> I was of course joking. I assumed you were as well.
>>
>> What is the point of (void*){ (long)0.0 }? I don't believe it's a
>> null pointer constant even in C23.
>
> The null pointer constant is (long)0.0, which it must be for the
> compound literal to work.
Depending on the context, a null pointer constant is not necessary for
the compound literal to work. Adapting your example from elsethread :
#include <stdio.h>
int main(void) {
void *np = (long)0.0;
printf(" null pointer : %p\n", (void*){ np });
}
> Besides making it obvious that (long)0.0
> is a null pointer constant, the compound literal is safer than
> using just a cast.
I fail to see how it's safer.
>> My example is.
>
> Your example actually has two null pointer constants:
It actually has four, but how is that relevant?
I wrote :
But surely ((void*)('/'/'/'-'/'/'/')) is more elegant.
The following are all null pointer constants :
'/'/'/'-'/'/'/'
('/'/'/'-'/'/'/')
(void*)('/'/'/'-'/'/'/')
((void*)('/'/'/'-'/'/'/'))
But I never said otherwise. I merely said that my example (the
outermost expression) is an NPC.
> the
> expression being casted, and the full expression casting a null
> pointer constant to (void*). But in neither case is that especially
> obvious. Also the expression you wrote is less safe. For example,
> if it had been written ((void*)('/'/'/'+'/'/'/')), the result would
> still be legal C, and compile without problem, but would very likely
> not be what was desired. By contrast, if the compound literal had
> been written (void*){ (long)1.0 }, it simply would not give a clean
> compile, indicating that something is likely askew.
One more time: It was a joke. I thought that was obvious when I wrote
it. If it wasn't, you know now.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-07-08 14:09 +0000 |
| Message-ID | <zqSiO.13381$OXD2.9845@fx47.iad> |
| In reply to | #386870 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >scott@slp53.sl.home (Scott Lurndal) writes: >> Ben Bacarisse <ben@bsb.me.uk> writes: >[...] >>>Do you always cast NULL to a pointer in those (admittedly rare) cases >>>when one needs to? >> >> I may have back in the days when I was using Version 6 C and >> AT&T C where >> >> $ grep NULL /work/reference/usl/uw2.01/usr/src/common/head/stddef.h >> #ifndef NULL >> #define NULL 0 >> >> >> I use gcc today and it defines NULL for C as >> >> #define NULL ((void *)0) > >Consider a variadic function that uses a null pointer to terminate the >argument list. Then I always use NULL cast to the appropriate pointer >type. > >For example, execl() requires a final argument that should be >`(char*)NULL`. > >On the other hand, execl() is specified by POSIX, which also happens to >require NULL to be of type void* -- and you can pretty much get away >with using a void* null pointer where a char* null pointer is expected. Yes, that would be my reading. > >But casting NULL to the appropriate type (checked by reading the man >page) requires less thought. Perhaps. For me, it is more rote than thought at this point. And it's been a couple of decades since I needed to call one of the exec functions directly :-) > >I just about always use NULL, not 0, when I want a null pointer >constant. Similarly, I use '\0', not 0, when I want a null character, >0.0 when I want a floating-point zero, and false when I want a Boolean >zero. I just like being explicit. I agree 100% with this. > >In C23, I'll use nullptr rather than NULL *if* I don't care about >portability to pre-C23 compilers. (I use nullptr in C++.) I haven't made the transition to nullptr in C++ yet, too many years of using NULL and code bases that need to compile with older standards (pre C++11, until very recently) - granted one might #define nullptr (void *)NULL
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2024-07-08 21:45 -0700 |
| Message-ID | <v6if96$18hur$1@dont-email.me> |
| In reply to | #386870 |
On 07/07/24 3:17 PM, Keith Thompson wrote: > > I just about always use NULL, not 0, when I want a null pointer > constant. Similarly, I use '\0', not 0, when I want a null character, > 0.0 when I want a floating-point zero, and false when I want a Boolean > zero. I just like being explicit. > Me too. But at the same time I realize that this is a habit forced upon my by circumstances, by necessity. C (as well as C++) at its beginning (and when I started to use the language) was not very well-suited for type-agnostic/DRY programming. It had a few odd features/idioms acknowledging the possibility, but by large both languages were predominantly type-aware or type-explicit. I reckon, this is actually what made you to "like" such explicitness. But it is pointless to talk about "liking" something, when one really had no choice. The moment C++ realized the full power of generic/template programming, it immediately rushed head-over-heels into type-agnostic programming style. It was `auto` and `decltype` initially, which then just opened the proverbial floodgates, triggering the avalanche of additional features targeted at the type-agnostic programming style. Many in C++ world still protest it, claiming that old-style type-explicit code is "easier to read", but they are nothing more than overgrown kids being reluctant to take the training wheels off their bikes (since they make it "easier to ride"). There no doubt anymore than type-agnostic programming is the next big thing for C++. The same goes for C. C is not C++, of course, but with the introduction of `typeof` in C23 and, hopefully, better `_Generic` appearing one of these days, one can hope that being type-explicit is a thing of the past in C as well. So, no. While I too prefer to use `NULL` for pointers and '\0' for character constants, I realize that do it out of deep-seated habit, or for nostalgic/luddite reasons mostly. Plain undecorated `0` as a universal type-agnostic constant should really be my choice everywhere today. -- Best regards, Andrey
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2024-07-08 21:49 -0700 |
| Message-ID | <v6ifg7$18p16$1@dont-email.me> |
| In reply to | #386909 |
On 07/08/24 9:45 PM, Andrey Tarasevich wrote: > > So, no. While I too prefer to use `NULL` for pointers and '\0' for > character constants, I realize that do it out of deep-seated habit, or > for nostalgic/luddite reasons mostly. Plain undecorated `0` as a > universal type-agnostic constant should really be my choice everywhere > today. ... although, one the second thought, one can probably start a Holy War about what a proper type-agnostic declaration of a `double` variable should look like double d = 0; or auto d = 0.0; -- Best regards, Andrey
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-07-11 02:42 +0000 |
| Message-ID | <v6ngq6$29e0c$2@dont-email.me> |
| In reply to | #386910 |
On Mon, 8 Jul 2024 21:49:10 -0700, Andrey Tarasevich wrote:
> ... although, one the second thought, one can probably start a Holy War
> about what a proper type-agnostic declaration of a `double` variable
> should look like
>
> double d = 0;
>
> or
>
> auto d = 0.0;
How about
integer, parameter :: useprec = kind(0.0d0)
real(kind = useprec) :: altitude, next_altitude, next_velocity, fuel_rate, elapsed
Not quite full generics, but useful nonetheless.
(From a program I posted on comp.lang.fortran a few weeks ago.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-07-08 22:58 -0700 |
| Message-ID | <87y16bw1hf.fsf@nosuchdomain.example.com> |
| In reply to | #386909 |
Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> On 07/07/24 3:17 PM, Keith Thompson wrote:
>> I just about always use NULL, not 0, when I want a null pointer
>> constant. Similarly, I use '\0', not 0, when I want a null character,
>> 0.0 when I want a floating-point zero, and false when I want a Boolean
>> zero. I just like being explicit.
>
> Me too.
>
> But at the same time I realize that this is a habit forced upon my by
> circumstances, by necessity. C (as well as C++) at its beginning (and
> when I started to use the language) was not very well-suited for
> type-agnostic/DRY programming. It had a few odd features/idioms
> acknowledging the possibility, but by large both languages were
> predominantly type-aware or type-explicit. I reckon, this is actually
> what made you to "like" such explicitness. But it is pointless to talk
> about "liking" something, when one really had no choice.
>
> The moment C++ realized the full power of generic/template
> programming, it immediately rushed head-over-heels into type-agnostic
> programming style. It was `auto` and `decltype` initially, which then
> just opened the proverbial floodgates, triggering the avalanche of
> additional features targeted at the type-agnostic programming
> style. Many in C++ world still protest it, claiming that old-style
> type-explicit code is "easier to read", but they are nothing more than
> overgrown kids being reluctant to take the training wheels off their
> bikes (since they make it "easier to ride"). There no doubt anymore
> than type-agnostic programming is the next big thing for C++.
>
> The same goes for C. C is not C++, of course, but with the
> introduction of `typeof` in C23 and, hopefully, better `_Generic`
> appearing one of these days, one can hope that being type-explicit is
> a thing of the past in C as well.
>
> So, no. While I too prefer to use `NULL` for pointers and '\0' for
> character constants, I realize that do it out of deep-seated habit, or
> for nostalgic/luddite reasons mostly. Plain undecorated `0` as a
> universal type-agnostic constant should really be my choice everywhere
> today.
Hmm. I like the idea of a type-agnostic way to express a "zero" value,
especially in a language that lets you write type-generic code. But I
don't think I like using 0 for that purpose, since 0 is *also* a
constant of the specific type int. C's use of 0 for all scalar types
strikes me more as an historical accident than a design feature.
And of course not all code needs to be type-agnostic.
In C++, {} seems to be an expression that gives you the default value of
any type (there are probably off-topic subtleties I'm missing). In C23,
it can be used as an initializer ({0} works in C17 and earlier), but
not as an expression.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-07-10 07:36 -0700 |
| Message-ID | <86r0c18gbl.fsf@linuxsc.com> |
| In reply to | #386917 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Hmm. I like the idea of a type-agnostic way to express a "zero" > value, [but] C's use of 0 for all scalar types strikes me more as > an historical accident than a design feature. I don't think it was an accident at all. It was chosen to be consistent with how if(), while(), !, ?:, and so forth, all act. There is a very consistent design philosophy there. Sometimes people who come from a strong Pascal background don't like it, but personally I find the C model easier and more convenient to work with than the Pascal model.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-07-10 14:15 -0700 |
| Message-ID | <87h6cxuexa.fsf@nosuchdomain.example.com> |
| In reply to | #386996 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Hmm. I like the idea of a type-agnostic way to express a "zero"
>> value, [but] C's use of 0 for all scalar types strikes me more as
>> an historical accident than a design feature.
>
> I don't think it was an accident at all. It was chosen to be
> consistent with how if(), while(), !, ?:, and so forth, all act.
> There is a very consistent design philosophy there. Sometimes
> people who come from a strong Pascal background don't like it,
> but personally I find the C model easier and more convenient to
> work with than the Pascal model.
In early C, int was in a very real sense the default type. In B,
types weren't even explicit, and IIRC variables were effectively "of
type int", or more precisely a 16-bit PDP-11 word. (I'm glossing
over some details of B, many of which I don't know). In that
context 0 made sense as a general-purpose "zero" value.
Modern C has moved away from making int some kind of default
(though it hasn't entirely done so).
What I dislike is the fact that 0 is *both* of the specific type
int *and* is commonly used as a general-purpose scalar 0.
I accept it because it's the way the language is defined, but
IMHO it's perhaps not an historical accident (you're right, it was
deliberate), but more of an historical relic.
Which is why I use 0 for integers, '\0' for characters, 0.0 for
floating-point, and NULL (or nullptr if it's available) for pointers.
If there were some general-purpose zero token that *isn't* of a
specific type (I mentioned "{}" upthread), I'd probably use that.
But it's not enough of a problem that I'd necessarily advocate a
language change. And if someone else consistently uses 0 in pointer
context, I'll waste about half a second being annoyed and then move on.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-08-11 20:52 -0700 |
| Message-ID | <865xs6gzyi.fsf@linuxsc.com> |
| In reply to | #387018 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>> Hmm. I like the idea of a type-agnostic way to express a "zero" >>> value, [but] C's use of 0 for all scalar types strikes me more as >>> an historical accident than a design feature. >> >> I don't think it was an accident at all. It was chosen to be >> consistent with how if(), while(), !, ?:, and so forth, all act. >> There is a very consistent design philosophy there. Sometimes >> people who come from a strong Pascal background don't like it, >> but personally I find the C model easier and more convenient to >> work with than the Pascal model. > > In early C, int was in a very real sense the default type. In B, > types weren't even explicit, and IIRC variables were effectively "of > type int", or more precisely a 16-bit PDP-11 word. (I'm glossing > over some details of B, many of which I don't know). In that > context 0 made sense as a general-purpose "zero" value. My comment is not about the type but about the value. That the constant 0 happens to be of type int is irrelevant to my conclusions.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-07-08 20:07 +0200 |
| Message-ID | <v6h9su$vkip$1@dont-email.me> |
| In reply to | #386866 |
On 08.07.2024 18:23, Ben Bacarisse wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
>> On 08.07.2024 12:18, Ben Bacarisse wrote:
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>>
>>>> What's superfluous to one is useful for others (e.g. for grep'ing
>>>> occurrences of a null-pointer value in source codes);
>>>
>>> This is been suggested twice now but I'm struggling to see why that is
>>> useful. I can see management wanting one to find all uses of a null
>>> pointer constant to check that they have all been replaced by the
>>> "safer" nullptr, but what's the value in searching for nullptr?
>>
>> Bug-tracking.
>
> Can you say more?
Frankly, no. Not more than has been already written (not only by me
but also by others) in a couple posts of this thread. It's so clear to
me that if it's not obvious I don't know what would help to explain
(i.e. without going into micro-management explanations). - If yet you
haven't experienced a necessity for an alpha pattern for the value 0,
and since you're an experienced IT expert, I suppose it's okay for you
as it was. - When it had been introduced in our development standards
there was no second opinion. With C's primitive pointer concept we had
so often issues that it was helpful to quickly find them. The 'null'
we used was not the only convention, also suffixing pointer variables
with '_ptr' (or camel-case as 'Ptr' in C++) helped to quickly gain
insights, especially in (but not restricted to) code of others. Besides
bug-tracking we had also other QA measures like code inspections that
took advantage of more explicit naming supported by 'null' or '_ptr'.
We tried to express as much as possible ("as C allows") by conventions
and additions to a class library we were using. (Also things like the
elsethread disrespectfully mentioned 'true' and 'false' literals; but
since there was no first class boolean type as in more sophisticated
HLL of that time this could not address all issues; but at least make
the programmers' intention clearer - cf. false positives/negatives -
and bugs easier to find.)
Janis
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-07-08 23:55 +0100 |
| Message-ID | <87sewjsdc5.fsf@bsb.me.uk> |
| In reply to | #386875 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > On 08.07.2024 18:23, Ben Bacarisse wrote: >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> >>> On 08.07.2024 12:18, Ben Bacarisse wrote: >>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >>>>> >>>>> What's superfluous to one is useful for others (e.g. for grep'ing >>>>> occurrences of a null-pointer value in source codes); >>>> >>>> This is been suggested twice now but I'm struggling to see why that is >>>> useful. I can see management wanting one to find all uses of a null >>>> pointer constant to check that they have all been replaced by the >>>> "safer" nullptr, but what's the value in searching for nullptr? >>> >>> Bug-tracking. >> >> Can you say more? > > Frankly, no. OK. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-07-10 17:28 +0200 |
| Message-ID | <v6m9bn$1vbsi$1@dont-email.me> |
| In reply to | #386894 |
On 09.07.2024 00:55, Ben Bacarisse wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > >> On 08.07.2024 18:23, Ben Bacarisse wrote: >>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >>> >>>> On 08.07.2024 12:18, Ben Bacarisse wrote: >>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >>>>>> >>>>>> What's superfluous to one is useful for others (e.g. for grep'ing >>>>>> occurrences of a null-pointer value in source codes); >>>>> >>>>> This is been suggested twice now but I'm struggling to see why that is >>>>> useful. I can see management wanting one to find all uses of a null >>>>> pointer constant to check that they have all been replaced by the >>>>> "safer" nullptr, but what's the value in searching for nullptr? >>>> >>>> Bug-tracking. >>> >>> Can you say more? >> >> Frankly, no. [...] > > OK. So the text you snipped from my reply did not trigger any insight? Another, last try... Compare it to 'enum' constants. When I code or debug I want to track (search and find) them by name not by integer number. Similar with the 'enum' bool type we introduced (when there was not yet a bool type existing in C or C++) with literal constants 'true' and 'false'. (Only two values, but still as important.) Similar with the dedicated pointer value 0 (these days we used the literal 'null'). (Only one value, still useful for tracking eq/ne comparisons and initializations.) Janis
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-07-11 00:25 +0100 |
| Message-ID | <87cynkommh.fsf@bsb.me.uk> |
| In reply to | #387002 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > On 09.07.2024 00:55, Ben Bacarisse wrote: >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> >>> On 08.07.2024 18:23, Ben Bacarisse wrote: >>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >>>> >>>>> On 08.07.2024 12:18, Ben Bacarisse wrote: >>>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >>>>>>> >>>>>>> What's superfluous to one is useful for others (e.g. for grep'ing >>>>>>> occurrences of a null-pointer value in source codes); >>>>>> >>>>>> This is been suggested twice now but I'm struggling to see why that is >>>>>> useful. I can see management wanting one to find all uses of a null >>>>>> pointer constant to check that they have all been replaced by the >>>>>> "safer" nullptr, but what's the value in searching for nullptr? >>>>> >>>>> Bug-tracking. >>>> >>>> Can you say more? >>> >>> Frankly, no. [...] >> >> OK. > > So the text you snipped from my reply did not trigger any insight? I didn't read it. You said you could not say more so I assumed what you'd written was not saying more but something else like repeating what you'd already said. > Another, last try... > Compare it to 'enum' constants. When I code or debug I want to track > (search and find) them by name not by integer number. > Similar with the 'enum' bool type we introduced (when there was not > yet a bool type existing in C or C++) with literal constants 'true' > and 'false'. (Only two values, but still as important.) > Similar with the dedicated pointer value 0 (these days we used the > literal 'null'). (Only one value, still useful for tracking eq/ne > comparisons and initializations.) Yes, you've said that before. You want to search for nullptr. I can't think of how that might help find a real bug, if that's what you mean by bug-tracking. I was hoping for a story... "Once I had this bug where... and if I'd been using nullptr I'd have found it a day earlier" kind of thing. I'd found a lot of bugs over the years, but I don't recall any that would have been easier to find had I been able to search for nullptr. I was looking for real-world insight here. Obviously one could make up a bug where p = nullptr; was written where, say, p = null - ptr; was intended, but that's not what I mean. Without such an example, your argument seems to be overly generic. Would you welcome the introduction of the keyword unity -- with the value 1 and type int -- into C because one could then search for it? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-07-12 14:08 +0200 |
| Message-ID | <v6r6c7$3122q$1@dont-email.me> |
| In reply to | #387028 |
On 11.07.2024 01:25, Ben Bacarisse wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> [...] >> Compare it to 'enum' constants. When I code or debug I want to track >> (search and find) them by name not by integer number. >> Similar with the 'enum' bool type we introduced (when there was not >> yet a bool type existing in C or C++) with literal constants 'true' >> and 'false'. (Only two values, but still as important.) >> Similar with the dedicated pointer value 0 (these days we used the >> literal 'null'). (Only one value, still useful for tracking eq/ne >> comparisons and initializations.) > > Yes, you've said that before. You want to search for nullptr. I can't > think of how that might help find a real bug, if that's what you mean by > bug-tracking. > > I was hoping for a story... "Once I had this bug where... and if I'd > been using nullptr I'd have found it a day earlier" kind of thing. I'd > found a lot of bugs over the years, but I don't recall any that would > have been easier to find had I been able to search for nullptr. > > I was looking for real-world insight here. Obviously one could make up > a bug where p = nullptr; was written where, say, p = null - ptr; was > intended, but that's not what I mean. > > Without such an example, your argument seems to be overly generic. That's why I had problems to "explain" the reasons to you; because it's so universal a property, so obvious (as I said), that I don't know what else I could say. (Likewise with "real-word examples".) What example could I give that explains that if you're looking for specific dedicated semantical values it's easier to look them up by [semantical] name than by a [ambiguous] number. Yes this speeds up detection of errors when doing code inspections (for bugs or as QA measure), and yes, this was helpful for program development and bug detection in [my professional and private] practice. > Would you welcome the introduction of the keyword unity -- with the > value 1 and type int -- into C because one could then search for it? No. (Please don't start to be ridiculous. - Or did you really miss the point? - No offense intended.) Janis
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-07-13 00:59 +0100 |
| Message-ID | <87y166jh60.fsf@bsb.me.uk> |
| In reply to | #387088 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > On 11.07.2024 01:25, Ben Bacarisse wrote: >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >>> [...] >>> Compare it to 'enum' constants. When I code or debug I want to track >>> (search and find) them by name not by integer number. >>> Similar with the 'enum' bool type we introduced (when there was not >>> yet a bool type existing in C or C++) with literal constants 'true' >>> and 'false'. (Only two values, but still as important.) >>> Similar with the dedicated pointer value 0 (these days we used the >>> literal 'null'). (Only one value, still useful for tracking eq/ne >>> comparisons and initializations.) >> >> Yes, you've said that before. You want to search for nullptr. I can't >> think of how that might help find a real bug, if that's what you mean by >> bug-tracking. >> >> I was hoping for a story... "Once I had this bug where... and if I'd >> been using nullptr I'd have found it a day earlier" kind of thing. I'd >> found a lot of bugs over the years, but I don't recall any that would >> have been easier to find had I been able to search for nullptr. >> >> I was looking for real-world insight here. Obviously one could make up >> a bug where p = nullptr; was written where, say, p = null - ptr; was >> intended, but that's not what I mean. >> >> Without such an example, your argument seems to be overly generic. > > That's why I had problems to "explain" the reasons to you; because > it's so universal a property, so obvious (as I said), that I don't > know what else I could say. Yes, that's been the clear for a while now. That's why, when you said you could not say more, I was happy to leave it at that (my "ok"). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-07-13 04:01 +0200 |
| Message-ID | <v6sn59$3dbk7$1@dont-email.me> |
| In reply to | #387116 |
On 13.07.2024 01:59, Ben Bacarisse wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 11.07.2024 01:25, Ben Bacarisse wrote: >>> [...] >>> Without such an example, your argument seems to be overly generic. >> >> That's why I had problems to "explain" the reasons to you; because >> it's so universal a property, so obvious (as I said), that I don't >> know what else I could say. > > Yes, that's been the clear for a while now. That's why, when you said > you could not say more, I was happy to leave it at that (my "ok"). You again strip the post where my try for an explanation follows: >> What example could I give that explains that if you're looking for >> specific dedicated semantical values it's easier to look them up >> by [semantical] name than by a [ambiguous] number. Are those semantical names so meaningless to you? Let's take the 'bool' sample; do you find it more helpful to look for numerical falues in the code than to look for standard literals like 'true' and 'false'? (It's not much different concerning 'NULL'.) (But okay, given your last response patterns you seem to not be interested.) Janis
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-07-15 00:00 +0100 |
| Message-ID | <87y163inp9.fsf@bsb.me.uk> |
| In reply to | #387120 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > On 13.07.2024 01:59, Ben Bacarisse wrote: >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >>> On 11.07.2024 01:25, Ben Bacarisse wrote: >>>> [...] >>>> Without such an example, your argument seems to be overly generic. >>> >>> That's why I had problems to "explain" the reasons to you; because >>> it's so universal a property, so obvious (as I said), that I don't >>> know what else I could say. >> >> Yes, that's been the clear for a while now. That's why, when you said >> you could not say more, I was happy to leave it at that (my "ok"). > > You again strip the post where my try for an explanation follows: Of course; I have nothing to say about your explanation. I understood it from the very first time you posted it (although I suppose I might be mistaken about that). Nothing about it is in dispute. Should I have kept it and ignored it? >>> What example could I give that explains that if you're looking for >>> specific dedicated semantical values it's easier to look them up >>> by [semantical] name than by a [ambiguous] number. > > Are those semantical names so meaningless to you? No, I get it. > Let's take the 'bool' sample; do you find it more helpful to look > for numerical falues in the code than to look for standard literals > like 'true' and 'false'? (It's not much different concerning 'NULL'.) I have no recollection of an occasion when searching for true or false has ever helped me to find a bug. If you do, please recount the story. That's the sort of thing that has been missing (for me). > (But okay, given your last response patterns you seem to not be > interested.) I have always been interested in hearing more about your experiences about what you called "bug-tracking". That's why I asked "can you say more?". And when you said "no" I thought that would be the end of it. (By the way, I still don't know what you mean by bug-tracking. I've assumed you mean tracking as in tracking down, i.e. finding and fixing bugs rather than the more usual meaning of logging and recording details of known bugs.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-07-13 04:18 +0200 |
| Message-ID | <v6so4v$3dg3t$1@dont-email.me> |
| In reply to | #387088 |
On 12.07.2024 14:08, Janis Papanagnou wrote: > On 11.07.2024 01:25, Ben Bacarisse wrote: > [...] >> Would you welcome the introduction of the keyword unity -- with the >> value 1 and type int -- into C because one could then search for it? > > No. [...] One addition here; you've been asking for a [general available] literal name for integer constants. Which is of course nonsense because we have no "specific dedicated semantical values" (as I wrote) and which is different from 'null', 'true', or 'false', which all are such dedicated values. But for specific applications it may make sense to define (for specific values) 'int' or 'float' literals. I've seen examples of software doing formal differentiation in Algol 68 and Simula. Despite the approach of both software versions were completely different, both code designers defined dedicated objects like 'zero' and 'one', because being neutral elements these objects serve a special purpose in the software architecture of their formal differentiation algorithm. 'pi' may be another example. So even if your statement above had obviously a different more ludicrous intention [concerning a general availability of such 'int' literals] there's specific applications where it's useful (or even necessary). Janis
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-07-17 09:26 -0700 |
| Message-ID | <86h6co56j1.fsf@linuxsc.com> |
| In reply to | #387088 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 11.07.2024 01:25, Ben Bacarisse wrote:
>
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>
>>> [...]
>>> Compare it to 'enum' constants. When I code or debug I want to track
>>> (search and find) them by name not by integer number.
>>> Similar with the 'enum' bool type we introduced (when there was not
>>> yet a bool type existing in C or C++) with literal constants 'true'
>>> and 'false'. (Only two values, but still as important.)
>>> Similar with the dedicated pointer value 0 (these days we used the
>>> literal 'null'). (Only one value, still useful for tracking eq/ne
>>> comparisons and initializations.)
Neither of these analogies illuminates the question, which is How
is searching for a null pointer value useful. The enum analogy
suffers both from being much more type specific and from being a
more distinguished value, unlike NULL which applies to all pointer
types, and almost certainly is more broadly used than any of the
named constants defined in an 'enum' type. The bool analogy is a
more faithful analogy but presents the same question: how is
searching for a constant like 'true' or 'false' useful? We might
want to know how a particular variable acquired a particular value
('true', say), but for that question it seems much more fruitful to
search for the variable, or where a particular function is called,
than it does for search for 'true' or 'false'. Also boolean values
can be the result of a C operator such as '<' or '&&', so searching
for 'true' or 'false' need not turn up the expression being sought.
In fact in the case of booleans I think it is much more likely that
a value being assigned comes from a C operator than it does from a
boolean constant.
>> Yes, you've said that before. You want to search for nullptr. I
>> can't think of how that might help find a real bug, if that's what
>> you mean by bug-tracking.
>>
>> I was hoping for a story... "Once I had this bug where... and if
>> I'd been using nullptr I'd have found it a day earlier" kind of
>> thing. I'd found a lot of bugs over the years, but I don't recall
>> any that would have been easier to find had I been able to search
>> for nullptr.
>>
>> I was looking for real-world insight here. Obviously one could
>> make up a bug where p = nullptr; was written where, say, p = null -
>> ptr; was intended, but that's not what I mean.
>>
>> Without such an example, your argument seems to be overly generic.
>
> That's why I had problems to "explain" the reasons to you; because
> it's so universal a property, so obvious (as I said), that I don't
> know what else I could say. (Likewise with "real-word examples".)
> What example could I give that explains that if you're looking for
> specific dedicated semantical values it's easier to look them up
> by [semantical] name than by a [ambiguous] number. Yes this speeds
> up detection of errors when doing code inspections (for bugs or as
> QA measure), and yes, this was helpful for program development and
> bug detection in [my professional and private] practice.
Ben explains exactly what he is looking for -- a story -- and you
respond by not giving him one. What's up with that? Your comment
that something is obvious, followed by an unanswered rhetorical
question, is totally lame. Ben is asking (I infer) precisely
because such a story or example is not obvious to him. I can say
for sure that it is not obvious to me.
>> Would you welcome the introduction of the keyword unity -- with the
>> value 1 and type int -- into C because one could then search for it?
>
> No. (Please don't start to be ridiculous. - Or did you really miss
> the point? - No offense intended.)
I think it is you who is missing the point. Ben's comment is not a
suggestion but a question. Moreover as I read the question it is a
sincere effort to gain some insight into what you think and why.
And in response rather than try to answer the question in any helpful
way, instead you ridicule him. This response does nothing to answer
his question, nor does it give the impression that you are really
listening. You might want to think about that if you want your
remarks here to be taken seriously.
I want to say something about the nature of newsgroup dialog.
Recently Ben and I had a lengthy exchange where we tried to sort
out our mutual misunderstandings of the other's reading of a
particular passage in the C standard. It wasn't easy to get to
the key underlying assumptions that prompted our respective
viewpoints. I know from first-hand experience that Ben is a
smart and thoughtful guy, but despite that we formed radically
different views about something that seemed "obvious" to both
of us. (I'm not sure how obvious the views were, in either
Ben's case or my own, but I do know it took a lot of explanation
on both sides to get to the point where we understood each
other, which is an indicator that we thought of our own views as
obvious.) I think the lesson here is that in many cases it is
the most "obvious" thoughts that are most in need of explanation.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-07-08 12:29 +0200 |
| Message-ID | <v6gf23$r5pf$1@dont-email.me> |
| In reply to | #386866 |
On 08.07.2024 12:18, Ben Bacarisse wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> >> What's superfluous to one is useful for others (e.g. for grep'ing >> occurrences of a null-pointer value in source codes); > > This is been suggested twice now but I'm struggling to see why that is > useful. I can see management wanting one to find all uses of a null > pointer constant to check that they have all been replaced by the > "safer" nullptr, but what's the value in searching for nullptr? Bug-tracking. Janis > [...]
[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