[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Gnulib and nullptr
From: |
Dmitrii Pasechnik |
Subject: |
Re: Gnulib and nullptr |
Date: |
Mon, 6 Feb 2023 22:05:25 +0000 |
On Mon, Feb 06, 2023 at 04:22:46PM -0500, Jeffrey Walton wrote:
> On Sun, Feb 5, 2023 at 9:45 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> >
> > On 2023-02-05 18:00, Bruno Haible wrote:
> > > Why call it 'c-nullptr', not 'nullptr'?
> >
> > I was worried about C++, not that I know much about it, and operated by
> > analogy with the name of m4/c-bool.m4. If 'nullptr' is a better name
> > then let's switch to it. I assume we'd also switch the file names, the
> > macro names, etc.
>
> In C++, nullptr is not convertible to an integral. So this no longer
> causes confusion:
>
> g(void*);
> g(int);
>
> g(nullptr) will always match g(void*). g(int) will never be matched,
> which could happen with g(NULL).
As compilers C++ compilers get stricter, more and more old C++ code
breaks due to NULL being of wrong type. I did quite a bit of patching
of such code replacing NULL with nullptr in the last few years.
Dima
- Re: Gnulib and nullptr, (continued)
- Re: Gnulib and nullptr, Paul Eggert, 2023/02/06
- Re: Gnulib and nullptr, Paul Eggert, 2023/02/07
- Re: Gnulib and nullptr, Bruno Haible, 2023/02/08
- Re: Gnulib and nullptr (and m4_provide_if), Paul Eggert, 2023/02/08
- Re: Gnulib and nullptr (and m4_provide_if), Akim Demaille, 2023/02/12
Re: Gnulib and nullptr, Bruno Haible, 2023/02/05
Re: Gnulib and nullptr, Bruno Haible, 2023/02/05