Why nullptr?

[DeMarcus]

Hi!

Why can't we just use the keyword null instead of nullptr?

Even though someone has defined null in an existing project,
the code will still compile and work since using 0 will be
backwards compatible.

/Daniel

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Tom Deseyn]

On Nov 10, 9:26 am, DeMarcus <use_my_alias_h...@hotmail.com> wrote:
> Hi!
>
> Why can't we just use the keyword null instead of nullptr?
>
> Even though someone has defined null in an existing project,
> the code will still compile and work since using 0 will be
> backwards compatible.

{ edits: quoted signature and banner removed. please don't quote extraneous
material such as the banner. -mod }

Juliet:
"What's in a name? That which we call a rose
By any other name would smell as sweet."
Romeo and Juliet (II, ii, 1-2)

rationale:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf

Wkr,

Tom

[Daniel Krügler]

On 10 Nov., 09:26, DeMarcus <use_my_alias_h...@hotmail.com> wrote:
> Hi!
>
> Why can't we just use the keyword null instead of nullptr?
>
> Even though someone has defined null in an existing project,
> the code will still compile and work since using 0 will be
> backwards compatible.

Neither of these arguments is correct, because nullptr is a keyword.
If user-code would try something like

const int null = 0;

given a C++0x compiler that would define null as the new keyword,
this code would become ill-formed, similar to user-code that attempts
to user other keywords in situations where they are not supported by
the language:

const int private = 0;

The second argument ("since using 0 will be backwards compatible")
is also wrong, otherwise it would be possible for a C++ compiler to

#define NULL nullptr

But this is not feasible, because user-code could have written code
that relied on the fact that NULL is an integral constant expression
of type int in this kind of code:

#include <cstddef>

void foo(int);

int main() {
foo(NULL);
}

which would break with NULL being changed to nullptr.

HTH & Greetings from Bremen,

Daniel Kr�gler

[Francis Glassborow]

DeMarcus wrote:
> Hi!
>
> Why can't we just use the keyword null instead of nullptr?
>
> Even though someone has defined null in an existing project,
> the code will still compile and work since using 0 will be
> backwards compatible.
>

We are trying to create a way in which the ambiguities between 0 as a
pointer constant and 0 as an int can be resolved. To maje matters worse
there is a great deal of code that abuses null by using it as a synonym
for 0.

[Jeff Schwab]

Francis Glassborow wrote:
> DeMarcus wrote:

>> Why can't we just use the keyword null instead of nullptr?

> We are trying to create a way in which the ambiguities between 0 as a

> pointer constant and 0 as an int can be resolved. To maje matters worse
> there is a great deal of code that abuses null by using it as a synonym
> for 0.

Maybe you can clarify: Why is any keyword needed here at all here? It
seems that default-constructed temporaries already do a good job as null
pointer rvalues, but and give the exact pointer type. If a
one-size-fits all nullptr is actually needed, why not something like this?

typedef void* void_pointer_t;
void_pointer_t const nullptr = void_pointer_t( );

[Nevin :-] Liber]

In article <INOdnY2ouJ3aW2fX...@giganews.com>,
Jeff Schwab <je...@schwabcenter.com> wrote:

> Maybe you can clarify: Why is any keyword needed here at all here?

You may wish to read the Stroustrup/Sutter proposal at
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf>
(unless there is a later one somewhere). It goes into the motivation
behind the proposal.

> If a
> one-size-fits all nullptr is actually needed, why not something like this?
>
> typedef void* void_pointer_t;
> void_pointer_t const nullptr = void_pointer_t( );

This is covered in section 1.2 of the proposal.

--
Nevin ":-)" Liber <mailto:ne...@eviloverlord.com> 773 961-1620

[Richard Corden]

Daniel Kr�gler wrote:

[...]

>
> The second argument ("since using 0 will be backwards compatible")
> is also wrong, otherwise it would be possible for a C++ compiler to
>
> #define NULL nullptr
>
> But this is not feasible, because user-code could have written code
> that relied on the fact that NULL is an integral constant expression
> of type int in this kind of code:
>
> #include <cstddef>
>
> void foo(int);
>
> int main() {
> foo(NULL);
> }
>
> which would break with NULL being changed to nullptr.

I have no problem with this code breaking, in fact I see it as being a
major positive that 'nullptr' will catch errors such as the above!

I therefore hope that all implementations do the following:

#define NULL nullptr

Richard

[Daniel Krügler]

On 16 Nov., 15:27, Richard Corden <richard.cor...@gmail.com> wrote:
> Daniel Kr�gler wrote:
>
> [...]
>
>
>
>
>
> > The second argument ("since using 0 will be backwards compatible")
> > is also wrong, otherwise it would be possible for a C++ compiler to
>
> > #define NULL nullptr
>
> > But this is not feasible, because user-code could have written code
> > that relied on the fact that NULL is an integral constant expression
> > of type int in this kind of code:
>
> > #include <cstddef>
>
> > void foo(int);
>
> > int main() {
> > foo(NULL);
> > }
>
> > which would break with NULL being changed to nullptr.
>
> I have no problem with this code breaking,

Sure, many of us would consider such a break as a positive
outcome. On the other hand, there exist large code bases,
that might not be amused, if that happens.

> in fact I see it as being a
> major positive that 'nullptr' will catch errors such as the above!

>From a pure C++ perspective this is not an error, because
this is the way the C++03 standard has been specified.
On retro-perspective one might say that it would have been
better, if that specification wasn't that specific.

> I therefore hope that all implementations do the following:
>
> #define NULL nullptr

I doubt they will, but I can think of special modes that
are provided with the same effect.

- Daniel Kr�gler