Switch to nullptr?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Switch to nullptr?

Rik-4
jwe,

As long as we're requiring C++11, shall we switch over to nullptr rather
than 0 or NULL?

As an example,

liboctave/system/oct-time.cc:           char *buf = 0;

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Switch to nullptr?

John W. Eaton
Administrator
On 04/27/2017 08:01 PM, Rik wrote:
> jwe,
>
> As long as we're requiring C++11, shall we switch over to nullptr rather
> than 0 or NULL?
>
> As an example,
>
> liboctave/system/oct-time.cc:           char *buf = 0;

If that's what we should be doing for correct C++ code then it seems
like a good change to me.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Switch to nullptr?

Rik-4
On 04/28/2017 08:42 AM, John W. Eaton wrote:

> On 04/27/2017 08:01 PM, Rik wrote:
>> jwe,
>>
>> As long as we're requiring C++11, shall we switch over to nullptr rather
>> than 0 or NULL?
>>
>> As an example,
>>
>> liboctave/system/oct-time.cc:           char *buf = 0;
>
> If that's what we should be doing for correct C++ code then it seems like
> a good change to me.

Yes.  The advantage is that nullptr is a literal constant (like 'true' and
'false') and part of the C++ language so available whenever the compiler
supports C++11.  And in terms of programming, it makes the programmer's
intent quite clear and can avoid accidental conversions of pointers to ints.

I made the change in this cset
(http://hg.savannah.gnu.org/hgweb/octave/rev/21baad6b35c4).

--Rik
   

Reply | Threaded
Open this post in threaded view
|

Re: Switch to nullptr?

Daniel Sebald
On 04/28/2017 03:36 PM, Rik wrote:

> On 04/28/2017 08:42 AM, John W. Eaton wrote:
>> On 04/27/2017 08:01 PM, Rik wrote:
>>> jwe,
>>>
>>> As long as we're requiring C++11, shall we switch over to nullptr rather
>>> than 0 or NULL?
>>>
>>> As an example,
>>>
>>> liboctave/system/oct-time.cc:           char *buf = 0;
>>
>> If that's what we should be doing for correct C++ code then it seems like
>> a good change to me.
>
> Yes.  The advantage is that nullptr is a literal constant (like 'true' and
> 'false') and part of the C++ language so available whenever the compiler
> supports C++11.  And in terms of programming, it makes the programmer's
> intent quite clear and can avoid accidental conversions of pointers to ints.
>
> I made the change in this cset
> (http://hg.savannah.gnu.org/hgweb/octave/rev/21baad6b35c4).
>
> --Rik

FYI, gvim recognizes "nullptr" and highlights with the constant-color
scheme when the file has extension .cpp, .c++ and .cc.  If the file
extension is just .c, there is no special highlight for "nullptr".  So
it's nice that is already addressed.

Is there a compiler setting that will warn when NULL is used to clear a
pointer rather than nullptr?

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Switch to nullptr?

Rik-4
On 04/28/2017 02:34 PM, Daniel J Sebald wrote:

> On 04/28/2017 03:36 PM, Rik wrote:
>> On 04/28/2017 08:42 AM, John W. Eaton wrote:
>>> On 04/27/2017 08:01 PM, Rik wrote:
>>>> jwe,
>>>>
>>>> As long as we're requiring C++11, shall we switch over to nullptr rather
>>>> than 0 or NULL?
>>>>
>>>> As an example,
>>>>
>>>> liboctave/system/oct-time.cc:           char *buf = 0;
>>>
>>> If that's what we should be doing for correct C++ code then it seems like
>>> a good change to me.
>>
>> Yes.  The advantage is that nullptr is a literal constant (like 'true' and
>> 'false') and part of the C++ language so available whenever the compiler
>> supports C++11.  And in terms of programming, it makes the programmer's
>> intent quite clear and can avoid accidental conversions of pointers to
>> ints.
>>
>> I made the change in this cset
>> (http://hg.savannah.gnu.org/hgweb/octave/rev/21baad6b35c4).
>>
>> --Rik
>
> FYI, gvim recognizes "nullptr" and highlights with the constant-color
> scheme when the file has extension .cpp, .c++ and .cc.  If the file
> extension is just .c, there is no special highlight for "nullptr".  So
> it's nice that is already addressed.
>
> Is there a compiler setting that will warn when NULL is used to clear a
> pointer rather than nullptr?

I don't think so.  NULL is just a macro that expands to 0 for C++ and (void
*)(0) for C.  Part of being backwards compatible means that nullptr has to
work seamlessly with both '0' and NULL.

--Rik


Reply | Threaded
Open this post in threaded view
|

Re: Switch to nullptr?

Daniel Sebald
On 04/28/2017 04:41 PM, Rik wrote:

> On 04/28/2017 02:34 PM, Daniel J Sebald wrote:
>> On 04/28/2017 03:36 PM, Rik wrote:
>>> On 04/28/2017 08:42 AM, John W. Eaton wrote:
>>>> On 04/27/2017 08:01 PM, Rik wrote:
>>>>> jwe,
>>>>>
>>>>> As long as we're requiring C++11, shall we switch over to nullptr rather
>>>>> than 0 or NULL?
>>>>>
>>>>> As an example,
>>>>>
>>>>> liboctave/system/oct-time.cc:           char *buf = 0;
>>>>
>>>> If that's what we should be doing for correct C++ code then it seems like
>>>> a good change to me.
>>>
>>> Yes.  The advantage is that nullptr is a literal constant (like 'true' and
>>> 'false') and part of the C++ language so available whenever the compiler
>>> supports C++11.  And in terms of programming, it makes the programmer's
>>> intent quite clear and can avoid accidental conversions of pointers to
>>> ints.
>>>
>>> I made the change in this cset
>>> (http://hg.savannah.gnu.org/hgweb/octave/rev/21baad6b35c4).
>>>
>>> --Rik
>>
>> FYI, gvim recognizes "nullptr" and highlights with the constant-color
>> scheme when the file has extension .cpp, .c++ and .cc.  If the file
>> extension is just .c, there is no special highlight for "nullptr".  So
>> it's nice that is already addressed.
>>
>> Is there a compiler setting that will warn when NULL is used to clear a
>> pointer rather than nullptr?
>
> I don't think so.  NULL is just a macro that expands to 0 for C++ and (void
> *)(0) for C.  Part of being backwards compatible means that nullptr has to
> work seamlessly with both '0' and NULL.
>
> --Rik

I suppose.  So nullptr is more restricted in its use, where NULL remains
prone to misuse but has to be so for compatibility.  Switching to that
variable, is there still a use for NULL somewhere in the code?

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Switch to nullptr?

Rik-4
On 04/28/2017 02:57 PM, Daniel J Sebald wrote:
> On 04/28/2017 04:41 PM, Rik wrote: >> On 04/28/2017 02:34 PM, Daniel J Sebald wrote: >>> On 04/28/2017 03:36 PM, Rik wrote: >>>> On 04/28/2017 08:42 AM, John W. Eaton wrote: >>>>> On 04/27/2017 08:01 PM, Rik wrote: >>>>>> jwe, >>>>>> >>>>>> As long as we're requiring C++11, shall we switch over to nullptr rather >>>>>> than 0 or NULL? >>>>>> >>>>>> As an example, >>>>>> >>>>>> liboctave/system/oct-time.cc:           char *buf = 0; >>>>> >>>>> If that's what we should be doing for correct C++ code then it seems like >>>>> a good change to me. >>>> >>>> Yes.  The advantage is that nullptr is a literal constant (like 'true' and >>>> 'false') and part of the C++ language so available whenever the compiler >>>> supports C++11.  And in terms of programming, it makes the programmer's >>>> intent quite clear and can avoid accidental conversions of pointers to >>>> ints. >>>> >>>> I made the change in this cset >>>> (http://hg.savannah.gnu.org/hgweb/octave/rev/21baad6b35c4). >>>> >>>> --Rik >>> >>> FYI, gvim recognizes "nullptr" and highlights with the constant-color >>> scheme when the file has extension .cpp, .c++ and .cc.  If the file >>> extension is just .c, there is no special highlight for "nullptr".  So >>> it's nice that is already addressed. >>> >>> Is there a compiler setting that will warn when NULL is used to clear a >>> pointer rather than nullptr? >> >> I don't think so.  NULL is just a macro that expands to 0 for C++ and (void >> *)(0) for C.  Part of being backwards compatible means that nullptr has to >> work seamlessly with both '0' and NULL. >> >> --Rik > > I suppose.  So nullptr is more restricted in its use, where NULL remains prone to misuse but has to be so for compatibility.  Switching to that variable, is there still a use for NULL somewhere in the code? >

There are one or two places left in the code where I couldn't tell whether switching would cause a problem so I left them alone.

# This is wrapped in a Windows-only #ifdef.  I don't know what Microsoft lib will return
corefcn/sysdep.cc:188:  if (hShell != NULL)
dldfcn/__osmesa_print__.cc:126:  OSMesaContext ctx = OSMesaCreateContextExt (OSMESA_RGBA, 16, 0, 0, NULL);

# Okay, I looked up the libsndfile API and these could be replaced with nullptr.
dldfcn/audioread.cc:526:  sf_command (NULL, SFC_GET_FORMAT_SUBTYPE_COUNT, &count, sizeof (int));
dldfcn/audioread.cc:532:      sf_command (NULL, SFC_GET_FORMAT_SUBTYPE, &info, sizeof (info));
dldfcn/audioread.cc:569:  sf_command (NULL, SFC_GET_FORMAT_MAJOR_COUNT, &count, sizeof (int));
dldfcn/audioread.cc:575:      sf_command (NULL, SFC_GET_FORMAT_MAJOR, &info, sizeof (info));

# Unclear from API which says third arg is of type jclass
octave-value/ov-java.cc:1512:      jobjectArray array = jni_env->NewObjectArray (n, scls, NULL);

# LLVM, and nobody uses the jit anymore anyways, so I didn't try and figure this one out.
parse-tree/jit-typeinfo.cc:1558:                                                  izero, NULL);

--Rik


Reply | Threaded
Open this post in threaded view
|

Re: Switch to nullptr?

John W. Eaton
Administrator
On 04/28/2017 06:13 PM, Rik wrote:

> There are one or two places left in the code where I couldn't tell
> whether switching would cause a problem so I left them alone.
>
> # This is wrapped in a Windows-only #ifdef.  I don't know what Microsoft
> lib will return
> corefcn/sysdep.cc:188:  if (hShell != NULL)

This could just be

   if (hShell)

> dldfcn/__osmesa_print__.cc:126:  OSMesaContext ctx =
> OSMesaCreateContextExt (OSMESA_RGBA, 16, 0, 0, NULL);

I always converted any uses of NULL in C++ code to just be 0.  The
function has to have a prototype and 0 should be fine.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Switch to nullptr?

Daniel Sebald
On 04/28/2017 05:58 PM, John W. Eaton wrote:

> On 04/28/2017 06:13 PM, Rik wrote:
>
>> There are one or two places left in the code where I couldn't tell
>> whether switching would cause a problem so I left them alone.
>>
>> # This is wrapped in a Windows-only #ifdef.  I don't know what Microsoft
>> lib will return
>> corefcn/sysdep.cc:188:  if (hShell != NULL)
>
> This could just be
>
>   if (hShell)
>
>> dldfcn/__osmesa_print__.cc:126:  OSMesaContext ctx =
>> OSMesaCreateContextExt (OSMESA_RGBA, 16, 0, 0, NULL);
>
> I always converted any uses of NULL in C++ code to just be 0.  The
> function has to have a prototype and 0 should be fine.
>
> jwe

If I understand correctly, the danger in C++ is that overloaded
functions are ambiguous when NULL is used, e.g., say there is some
function for which

   void OSMesaCreateContextExt (,,,, int);
   void OSMesaCreateContextExt (,,,, drvr *);

then NULL for the last input will choose the former version.  Now, I
doubt OSMesaCreatedContextExt is overloaded, but generally using 0
instead of NULL effectively explicitly does the implicit cast that the
use of NULL would result in.  It might be worth tacking on an explicit
cast in those cases where 0 is used, e.g.,

   OSMesaCreateContextExt (OSMESA_RGBA, 16, 0, 0, (OSMesaContext)0);
   jobjectArray array = jni_env->NewObjectArray (n, scls, (jclass)0);

Dan