|
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 |
[Prev in Thread] | Current Thread | [Next in Thread] |