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

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

Re: nullptr in C

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: nullptr in C Thiago Adams <thiago.adams@gmail.com> - 2019-03-22 12:14 -0700
    Re: nullptr in C James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-22 13:29 -0700
      Re: nullptr in C Thiago Adams <thiago.adams@gmail.com> - 2019-03-24 04:51 -0700
        Re: nullptr in C William Ahern <william@25thandClement.com> - 2019-03-25 06:50 -0700
        Re: nullptr in C James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-25 11:37 -0700
          Re: nullptr in C Thiago Adams <thiago.adams@gmail.com> - 2019-03-25 12:01 -0700
            Re: nullptr in C James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-25 12:23 -0700
              Re: nullptr in C Ian Collins <ian-news@hotmail.com> - 2019-03-26 08:33 +1300
                Re: nullptr in C James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-25 12:58 -0700
                  Re: nullptr in C Ian Collins <ian-news@hotmail.com> - 2019-03-26 10:25 +1300
              Re: nullptr in C Keith Thompson <kst-u@mib.org> - 2019-03-25 13:15 -0700
                Re: nullptr in C James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-25 13:21 -0700

#142256 — Re: nullptr in C

On Wednesday, August 22, 2018 at 9:53:12 AM UTC-3, Thiago Adams wrote:
> Considering nullptr is a keyword in C++ and considering
> many people (including me) try to keep the C code compiling
> in C++ should we adopt it as a macro in C?
> 
> I can see some similarities with bool in C.
> 
> When I include:
> 
> #include <stdbool.h>
> 
> the code works with bool , true , false in C and C++.
> 
> So.. I was thinking in 
> 
> #include <stdnull.h>
> 
> and create nullptr macro if the code is comping in C.
> 
> The other option could be define NULL as nullptr if the
> compiler is C++ and use NULL everywhere.
> 
> Have you ever make this question to yourself?
> What to do?

I changed my mind and I don't think adding nullptr is a good idea.

One difference between adding _Bool into the language is that BOOL 
was never added into the language headers. (Am I right? I didn't find
BOOL or TRUE FALSE at the language specification).

On the other hand if you search for NULL at the standard you will
find that NULL is defined in stddef.h

This means that adding _Bool didn't added a new way to declare booleans,
but adding nullptr will create this confusion that is two ways of 
writing code that means NULL.

In C we also have different ((void*)0) conversion rules compared with
C++ that is more strict.

Then for C, I believe that the literal that corresponds nullptr already
exists and it is ((void*)0).

What could be done is adding flags to static analysis to decide what
to do with ((void*)0) conversions.

[toc] | [next] | [standalone]

#142263

On Friday, March 22, 2019 at 3:14:48 PM UTC-4, Thiago Adams wrote:
> On Wednesday, August 22, 2018 at 9:53:12 AM UTC-3, Thiago Adams wrote:
> > Considering nullptr is a keyword in C++ and considering
> > many people (including me) try to keep the C code compiling
> > in C++ should we adopt it as a macro in C?
> > 
> > I can see some similarities with bool in C.
> > 
> > When I include:
> > 
> > #include <stdbool.h>
> > 
> > the code works with bool , true , false in C and C++.
> > 
> > So.. I was thinking in 
> > 
> > #include <stdnull.h>
> > 
> > and create nullptr macro if the code is comping in C.
> > 
> > The other option could be define NULL as nullptr if the
> > compiler is C++ and use NULL everywhere.
> > 
> > Have you ever make this question to yourself?
> > What to do?
> 
> I changed my mind and I don't think adding nullptr is a good idea.
> 
> One difference between adding _Bool into the language is that BOOL 
> was never added into the language headers. (Am I right? I didn't find
> BOOL or TRUE FALSE at the language specification).

That's true, but only because C is a case sensitive language.

Section 7.18:

"The header <stdbool.h> defines four macros.
2 The macro
        bool
  expands to _Bool.
3 The remaining three macros are suitable for use in #if
  preprocessing directives. They are
        true
  which expands to the integer constant 1,
        false
  which expands to the integer constant 0, and
        _ _bool_true_false_are_defined
  which expands to the integer constant 1."

> This means that adding _Bool didn't added a new way to declare booleans,

Actually, C has two ways to declare booleans, both of which were added to the language at the same time: _Bool and bool.

> but adding nullptr will create this confusion that is two ways of 
> writing code that means NULL.

I think you mean "means a null pointer constant". NULL and nullptr would
be two different macros that both expand to be a null pointer constant,
but there's already a huge variety of ways of writing one (for instance,
('\004'/5ULL)); having one additional way wouldn't be a big deal.

The key thing that drove the addition of nullptr to C++ was the fact
that NULL was required to expand to an expression with integer type and
a value of 0. Such an expression can always be used as either a null
pointer constant and as an ordinary integer. nullptr can only be used as
a null pointer constant.

In C, NULL is already allowed to expand to (void*)0, which is not an
integer, so a simpler change than adding nullptr would be to require
that NULL expand to an expression with pointer type. No strictly
conforming code would be broken by such a change. C++ didn't have that
option.

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

#142336

On Friday, March 22, 2019 at 5:29:35 PM UTC-3, James Kuyper wrote:
> On Friday, March 22, 2019 at 3:14:48 PM UTC-4, Thiago Adams wrote:
> > On Wednesday, August 22, 2018 at 9:53:12 AM UTC-3, Thiago Adams wrote:
> > > Considering nullptr is a keyword in C++ and considering
> > > many people (including me) try to keep the C code compiling
> > > in C++ should we adopt it as a macro in C?
> > > 
> > > I can see some similarities with bool in C.
> > > 
> > > When I include:
> > > 
> > > #include <stdbool.h>
> > > 
> > > the code works with bool , true , false in C and C++.
> > > 
> > > So.. I was thinking in 
> > > 
> > > #include <stdnull.h>
> > > 
> > > and create nullptr macro if the code is comping in C.
> > > 
> > > The other option could be define NULL as nullptr if the
> > > compiler is C++ and use NULL everywhere.
> > > 
> > > Have you ever make this question to yourself?
> > > What to do?
> > 
> > I changed my mind and I don't think adding nullptr is a good idea.
> > 
> > One difference between adding _Bool into the language is that BOOL 
> > was never added into the language headers. (Am I right? I didn't find
> > BOOL or TRUE FALSE at the language specification).
> 
> That's true, but only because C is a case sensitive language.
> 
> Section 7.18:
> 
> "The header <stdbool.h> defines four macros.
> 2 The macro
>         bool
>   expands to _Bool.
> 3 The remaining three macros are suitable for use in #if
>   preprocessing directives. They are
>         true
>   which expands to the integer constant 1,
>         false
>   which expands to the integer constant 0, and
>         _ _bool_true_false_are_defined
>   which expands to the integer constant 1."
> 
> > This means that adding _Bool didn't added a new way to declare booleans,
> 
> Actually, C has two ways to declare booleans, both of which were added to the language at the same time: _Bool and bool.

Yes, I was discarding the direct use of _Bool in my mind.
Does anyone uses _Bool instead of bool ?

Thinking in this way, if we had _Null we could leave 
it just to implement NULL and not use it directly, but I 
cannot see other advantages over ((void*)0). Like you said
C doesn't have the same needs of C++.

What worries me is the mess caused by may types of styles
inside the same source code. I think many companies using
C++ are facing these questions of style.

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

#142408

Thiago Adams <thiago.adams@gmail.com> wrote:
> On Friday, March 22, 2019 at 5:29:35 PM UTC-3, James Kuyper wrote:
<snip>
>> Actually, C has two ways to declare booleans, both of which were added to
>> the language at the same time: _Bool and bool.
> 
> Yes, I was discarding the direct use of _Bool in my mind.
> Does anyone uses _Bool instead of bool ?

I use _Bool to avoid ambiguity and potential correctness issues for when a
header is compiled with C++.

I also prefer _Static_assert over static_assert after encountering an issue
between a glibc <assert.h> header and GCC versions. (I forget whether the
issue was an old glibc and new GCC or new glibc and old GCC.)

> Thinking in this way, if we had _Null we could leave 
> it just to implement NULL and not use it directly, but I 
> cannot see other advantages over ((void*)0). Like you said
> C doesn't have the same needs of C++.
> 
> What worries me is the mess caused by may types of styles
> inside the same source code. I think many companies using
> C++ are facing these questions of style.

The magnitude of consistency issues in C++ is simply incomparable to C.

Using _Bool over bool is mostly an aesthetic issue that one can get over
very quickly. While there may be good reasons for using one over the other,
those reasons mostly implicate language interoperability issues and don't
reflect substantive C language complexity (e.g. not an example of TMTOWTDI).
Someone doesn't need to understand why one was chosen over the other--as far
as C is concerned they have identical behavior, and that's the end of it.

Indeed, _Bool vs bool, _Static_assert vs static_assert, etc, are more
reflective of C++ or C/C++ interoperability than of C, per se.

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

#142423

On Sunday, March 24, 2019 at 7:52:10 AM UTC-4, Thiago Adams wrote:
> On Friday, March 22, 2019 at 5:29:35 PM UTC-3, James Kuyper wrote:
> > On Friday, March 22, 2019 at 3:14:48 PM UTC-4, Thiago Adams wrote:
...
> > > This means that adding _Bool didn't added a new way to declare booleans,
> > 
> > Actually, C has two ways to declare booleans, both of which were added to the language at the same time: _Bool and bool.
> 
> Yes, I was discarding the direct use of _Bool in my mind.
> Does anyone uses _Bool instead of bool ?

Yes, I routinely use _Bool, if only to avoid having to
#include <stdbool.h>. In my experience, the need to avoid a conflicting
definition of "bool" comes up only rarely, but often enough to justify
avoiding it's use. I almost never need to write code that will compile
as both C and C++ code, with the same meaning.

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

#142425

On Monday, March 25, 2019 at 3:37:16 PM UTC-3, James Kuyper wrote:
> On Sunday, March 24, 2019 at 7:52:10 AM UTC-4, Thiago Adams wrote:
> > On Friday, March 22, 2019 at 5:29:35 PM UTC-3, James Kuyper wrote:
> > > On Friday, March 22, 2019 at 3:14:48 PM UTC-4, Thiago Adams wrote:
> ...
> > > > This means that adding _Bool didn't added a new way to declare booleans,
> > > 
> > > Actually, C has two ways to declare booleans, both of which were added to the language at the same time: _Bool and bool.
> > 
> > Yes, I was discarding the direct use of _Bool in my mind.
> > Does anyone uses _Bool instead of bool ?
> 
> Yes, I routinely use _Bool, if only to avoid having to
> #include <stdbool.h>. In my experience, the need to avoid a conflicting
> definition of "bool" comes up only rarely, but often enough to justify
> avoiding it's use. I almost never need to write code that will compile
> as both C and C++ code, with the same meaning.

In this case, what do you use for 'true' and 'false' ? 

(Both macros are defined in stdbool.h)

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

#142429

On Monday, March 25, 2019 at 3:02:11 PM UTC-4, Thiago Adams wrote:
> On Monday, March 25, 2019 at 3:37:16 PM UTC-3, James Kuyper wrote:
> > On Sunday, March 24, 2019 at 7:52:10 AM UTC-4, Thiago Adams wrote:
> > > On Friday, March 22, 2019 at 5:29:35 PM UTC-3, James Kuyper wrote:
> > > > On Friday, March 22, 2019 at 3:14:48 PM UTC-4, Thiago Adams wrote:
> > ...
> > > > > This means that adding _Bool didn't added a new way to declare booleans,
> > > > 
> > > > Actually, C has two ways to declare booleans, both of which were added to the language at the same time: _Bool and bool.
> > > 
> > > Yes, I was discarding the direct use of _Bool in my mind.
> > > Does anyone uses _Bool instead of bool ?
> > 
> > Yes, I routinely use _Bool, if only to avoid having to
> > #include <stdbool.h>. In my experience, the need to avoid a conflicting
> > definition of "bool" comes up only rarely, but often enough to justify
> > avoiding it's use. I almost never need to write code that will compile
> > as both C and C++ code, with the same meaning.
> 
> In this case, what do you use for 'true' and 'false' ? 
> 
> (Both macros are defined in stdbool.h)

if(condition)
if(!condition)

Assuming the condition variable is suitably named, that should be a very
clear, obvious way of using it.

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

#142430

On 26/03/2019 08:23, James Kuyper wrote:
> On Monday, March 25, 2019 at 3:02:11 PM UTC-4, Thiago Adams wrote:
>> On Monday, March 25, 2019 at 3:37:16 PM UTC-3, James Kuyper wrote:
>>> On Sunday, March 24, 2019 at 7:52:10 AM UTC-4, Thiago Adams wrote:
>>>> On Friday, March 22, 2019 at 5:29:35 PM UTC-3, James Kuyper wrote:
>>>>> On Friday, March 22, 2019 at 3:14:48 PM UTC-4, Thiago Adams wrote:
>>> ...
>>>>>> This means that adding _Bool didn't added a new way to declare booleans,
>>>>>
>>>>> Actually, C has two ways to declare booleans, both of which were added to the language at the same time: _Bool and bool.
>>>>
>>>> Yes, I was discarding the direct use of _Bool in my mind.
>>>> Does anyone uses _Bool instead of bool ?
>>>
>>> Yes, I routinely use _Bool, if only to avoid having to
>>> #include <stdbool.h>. In my experience, the need to avoid a conflicting
>>> definition of "bool" comes up only rarely, but often enough to justify
>>> avoiding it's use. I almost never need to write code that will compile
>>> as both C and C++ code, with the same meaning.
>>
>> In this case, what do you use for 'true' and 'false' ?
>>
>> (Both macros are defined in stdbool.h)
> 
> if(condition)
> if(!condition)

As a function parameter?

> Assuming the condition variable is suitably named, that should be a very
> clear, obvious way of using it.

-- 
Ian.

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

#142432

On Monday, March 25, 2019 at 3:33:56 PM UTC-4, Ian Collins wrote:
> On 26/03/2019 08:23, James Kuyper wrote:
> > On Monday, March 25, 2019 at 3:02:11 PM UTC-4, Thiago Adams wrote:
> >> On Monday, March 25, 2019 at 3:37:16 PM UTC-3, James Kuyper wrote:
> >>> On Sunday, March 24, 2019 at 7:52:10 AM UTC-4, Thiago Adams wrote:
> >>>> On Friday, March 22, 2019 at 5:29:35 PM UTC-3, James Kuyper wrote:
> >>>>> On Friday, March 22, 2019 at 3:14:48 PM UTC-4, Thiago Adams wrote:
> >>> ...
> >>>>>> This means that adding _Bool didn't added a new way to declare booleans,
> >>>>>
> >>>>> Actually, C has two ways to declare booleans, both of which were added to the language at the same time: _Bool and bool.
> >>>>
> >>>> Yes, I was discarding the direct use of _Bool in my mind.
> >>>> Does anyone uses _Bool instead of bool ?
> >>>
> >>> Yes, I routinely use _Bool, if only to avoid having to
> >>> #include <stdbool.h>. In my experience, the need to avoid a conflicting
> >>> definition of "bool" comes up only rarely, but often enough to justify
> >>> avoiding it's use. I almost never need to write code that will compile
> >>> as both C and C++ code, with the same meaning.
> >>
> >> In this case, what do you use for 'true' and 'false' ?
> >>
> >> (Both macros are defined in stdbool.h)
> > 
> > if(condition)
> > if(!condition)
> 
> As a function parameter?
> 
> > Assuming the condition variable is suitably named, that should be a very
> > clear, obvious way of using it.

function(boolean_expression)

I'm not saying the issue never comes up, but in most cases where I've
used _Bool, explicit use of either true or false is unnecessary. This is
probably the result of writing C code for more than three decades, and
not having "true" or "false" available as part of the language for most
of that time (the last time I worked on MODIS code, I was still covered
by a 1997 coding guideline that required me to write for C94 (C90 + first
two TC's)). I got pretty good at writing code that didn't need to use
them, which isn't very difficult.
The C++ code that I'm working on right now makes extensive use of true
or false to initialize bool variables in all constructors - even for
non-static data members that are explicitly set to some other value later
on in the same constructor.

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

#142442

On 26/03/2019 08:58, James Kuyper wrote:
> On Monday, March 25, 2019 at 3:33:56 PM UTC-4, Ian Collins wrote:
>> On 26/03/2019 08:23, James Kuyper wrote:
>>> On Monday, March 25, 2019 at 3:02:11 PM UTC-4, Thiago Adams wrote:
>>>> On Monday, March 25, 2019 at 3:37:16 PM UTC-3, James Kuyper wrote:
>>>>> On Sunday, March 24, 2019 at 7:52:10 AM UTC-4, Thiago Adams wrote:
>>>>>> On Friday, March 22, 2019 at 5:29:35 PM UTC-3, James Kuyper wrote:
>>>>>>> On Friday, March 22, 2019 at 3:14:48 PM UTC-4, Thiago Adams wrote:
>>>>> ...
>>>>>>>> This means that adding _Bool didn't added a new way to declare booleans,
>>>>>>>
>>>>>>> Actually, C has two ways to declare booleans, both of which were added to the language at the same time: _Bool and bool.
>>>>>>
>>>>>> Yes, I was discarding the direct use of _Bool in my mind.
>>>>>> Does anyone uses _Bool instead of bool ?
>>>>>
>>>>> Yes, I routinely use _Bool, if only to avoid having to
>>>>> #include <stdbool.h>. In my experience, the need to avoid a conflicting
>>>>> definition of "bool" comes up only rarely, but often enough to justify
>>>>> avoiding it's use. I almost never need to write code that will compile
>>>>> as both C and C++ code, with the same meaning.
>>>>
>>>> In this case, what do you use for 'true' and 'false' ?
>>>>
>>>> (Both macros are defined in stdbool.h)
>>>
>>> if(condition)
>>> if(!condition)
>>
>> As a function parameter?
>>
>>> Assuming the condition variable is suitably named, that should be a very
>>> clear, obvious way of using it.
> 
> function(boolean_expression)
> 
> I'm not saying the issue never comes up, but in most cases where I've
> used _Bool, explicit use of either true or false is unnecessary. This is
> probably the result of writing C code for more than three decades, and
> not having "true" or "false" available as part of the language for most
> of that time (the last time I worked on MODIS code, I was still covered
> by a 1997 coding guideline that required me to write for C94 (C90 + first
> two TC's)). I got pretty good at writing code that didn't need to use
> them, which isn't very difficult.
> The C++ code that I'm working on right now makes extensive use of true
> or false to initialize bool variables in all constructors - even for
> non-static data members that are explicitly set to some other value later
> on in the same constructor.

A smell for discussion in another place!

-- 
Ian.

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

#142435

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On Monday, March 25, 2019 at 3:02:11 PM UTC-4, Thiago Adams wrote:
[...]
>> In this case, what do you use for 'true' and 'false' ? 
>> 
>> (Both macros are defined in stdbool.h)
>
> if(condition)
> if(!condition)
>
> Assuming the condition variable is suitably named, that should be a very
> clear, obvious way of using it.

What about this?

    _Bool condition = false;

Do you just never find a need to write something like that?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#142438

On Monday, March 25, 2019 at 4:15:11 PM UTC-4, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> > On Monday, March 25, 2019 at 3:02:11 PM UTC-4, Thiago Adams wrote:
> [...]
> >> In this case, what do you use for 'true' and 'false' ? 
> >> 
> >> (Both macros are defined in stdbool.h)
> >
> > if(condition)
> > if(!condition)
> >
> > Assuming the condition variable is suitably named, that should be a very
> > clear, obvious way of using it.
> 
> What about this?
> 
>     _Bool condition = false;
> 
> Do you just never find a need to write something like that?

Not "never", but "seldom".

[toc] | [prev] | [standalone]

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

csiph-web