octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Switch to nullptr?


From: Rik
Subject: Re: Switch to nullptr?
Date: Fri, 28 Apr 2017 15:13:42 -0700

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 via email to

[Prev in Thread] Current Thread [Next in Thread]