Re: Switch to nullptr?

[Daniel J 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