'NULL' undeclared (first use this function)

Is there a reason my compiler would say 'NULL' undeclared (first use this function) ?

To my knowledge 'NULL' is not a function.

add this

Code:

---

#define NULL 0

---

NULL gets defined in stdlib.h I believe.

NULL is defined in <cstdlib> or <cstddef>. You need to include them in the file.

Tough, since this is C++ I recommend using 0 instead of null. This will make ambiguity errors arising from the value being treated as an integer more obvious.

Quote:

---

Originally Posted by King Mir

Tough, since this is C++ I recommend using 0 instead of null. This will make ambiguity errors arising from the value being treated as an integer more obvious.

---

Can you elaborate on that a bit? I always use NULL for pointers.

NULL and 0 are the same thing.
NULL improves readability IMO and I also use it for pointers.

I tend to use NULL for C++ specific code, with Stroustrup's reasoning:

Quote:

---

In C++, the definition of NULL is 0, so there is only an aesthetic difference. I prefer to avoid macros, so I use 0. Another problem with NULL is that people sometimes mistakenly believe that it is different from 0 and/or not an integer.

---

Has NULL ever been defined as anything else in any C or C++ standard?

Quote:

---

Originally Posted by sand_man

Has NULL ever been defined as anything else in any C or C++ standard?

---

In C, NULL is defined as "an implementation-defined null pointer constant"; I think all the ones I've seen are cast to (void *).

But Laserlight, Stroustrup seems to say that he prefers using '0' instead of 'NULL' for it is a macro, while you are using this argument to use NULL instead of 0?

Quote:

---

Originally Posted by sirconnorstack

Is there a reason my compiler would say 'NULL' undeclared (first use this function) ?

To my knowledge 'NULL' is not a function.

---

I think you are misunderstanding the error message: First use in this function means that it is only recorded as undeclared ONCE, not every time it's being used (because it's usually only ONE mistake to not declare something - and the compiler telling you that 35 times because that's how many times the variable occurs in the code isn't really going to help).

--
Mats

Quote:

---

Originally Posted by cpjust

Can you elaborate on that a bit? I always use NULL for pointers.

---

The ambiguity usually occurs when functions are overloaded to take either a pointer or an integer.

For example:

Code:

---

string eg;
eg+= NULL;

---

Now in this case adding null to a sting does not make sense. But the result is not what you'd expect. string has 3 operator+=, one for strings, one for char *, and one for chars. I think the compiler will complain of ambiguity, although it might just treat NULL as a char.

But this is wrong use. You should never add NULL to something.
You set NULL to pointers you want to point nowhere, and not much else. If you do, the NULL loses its meaning!

There are other less contrived possibilities.

Another situation that ambiguity occurs is with function template parameter deduction. For example:

Code:

---

make_pair(NULL,0);

---

Again I'm not sure if that would give an error or create a pair of integers. Either way, the mistake is not obvious unless 0 is used in place of NULL.

I use null to make the code more readable. When I see 0, I think "an int", when I see NULL, I think "a pointer".

Like so:

HWND hwnd = NULL;
long loop = 0;

Quote:

---

Originally Posted by MarkZWEERS

But Laserlight, Stroustrup seems to say that he prefers using '0' instead of 'NULL' for it is a macro, while you are using this argument to use NULL instead of 0?

---

Whoops, you are right: I made a typo error. (Two, actually. For some reason, I first wrote "NULL for NULL specific", then replaced the second "NULL" with "C++" but forgot to replace the first with "0". This NULL business is very strange.)

Quote:

---

Originally Posted by Yarin

I use null to make the code more readable. When I see 0, I think "an int", when I see NULL, I think "a pointer".

---

The problem is that the type says otherwise (NULL is an integer), so we have to wait for nullptr to come into play to avoid getting misled while getting extra readability.

Could someone refresh my memory... Why didn't C++ define NULL as (void*)0 ?

Quote:

---

Originally Posted by cpjust

Could someone refresh my memory... Why didn't C++ define NULL as (void*)0 ?

---

Because you can't SET a pointer of arbitrary type of the value of a void pointer. In C it's valid to copy void pointers in both directions, but C++ only allows "any" to void, but not void to any.

--
Mats

Quote:

---

Originally Posted by matsp

Because you can't SET a pointer of arbitrary type of the value of a void pointer. In C it's valid to copy void pointers in both directions, but C++ only allows "any" to void, but not void to any.

--
Mats

---

But it does allow int to pointer... that doesn't seem very consistent with that logic. At least void* is actually a pointer.
How is that nullptr going to work then? Is it going to be something like this (if this code was actually legal):

Code:

---

template <typename T> T* nullptr = 0;

---

Seeing as it's supposed to be a language element (built-in type), I don't think it isn't going to be defined anywhere. This is from what I understand anyway.
And regardless of whether NULL is an integer or not, I always stick it to pointers and thus define it as a pointer that points to nothing. We don't need to see the type "behind" it. We only need to see the word as a meaning.

Quote:

---

Originally Posted by cpjust

But it does allow int to pointer... that doesn't seem very consistent with that logic. At least void* is actually a pointer.
How is that nullptr going to work then? Is it going to be something like this (if this code was actually legal):

Code:

---

template <typename T> T* nullptr = 0;

---

---

But it only allows ONE integer value: zero! Try setting a pointer to (for example) 1, 7, 42 or -1 without a reinterpret_cast<T *>(n), and it will give you a compiler error.

--
Mats

nullptr will be of the special type nullptr_t and have very special rules regarding conversions.

Quote:

---

We only need to see the word as a meaning.

---

The compiler doesn't see it as having meaning; we need a 'nullptr' that really isn't an integer type.

Code:

---

template <typename T> T* nullptr = 0;

---

;_;

This pretty much works until compilers provide:

Code:

---

struct nullptr_t {template<typename T> operator T * (){return(0);}} nullptr;

---

Soma

What about this? . . . .

Code:

---

void *p = &nullptr;

---

Quote:

---

What about this?

---

I did say that it "pretty much works". It is easy to disable the address operator or induce a compiler error with any given message you might like. The problem of implementing 'nullptr_t' as proposed by the standard is a problem exclusively do to the unusual value semantics imposed by the throw/catch portion of the proposal. If you are going to offer a complaint, complain about that; it can't be match by any library tricker.

All of the "compiler diagnostic" stuff is a kind of "red herring". Compilers need better error messages for templates anyway; giving them an excuse not to improve in the area isn't a good thing.

Soma

Quote:

---

Originally Posted by phantomotap

The compiler doesn't see it as having meaning; we need a 'nullptr' that really isn't an integer type.

---

The only thing I see bad about NULL is that it can't be reliably overloaded.
You'd be overloading the whole int-range and that means any integer would be accepted.
Although the compiler might be able to do an implicit conversion to a T* type, but I'm not sure how well it works with overloaded operators...

I don't see NULL as wrong at all, but I would love to see it as a non-integer type, so that it can only be applied to pointers.

0 is c++:NULL is c.
It's as simple as that.

Quote:

---

Originally Posted by lruc

0 is c++:NULL is c.
It's as simple as that.

---

So if I see the following line in a piece of code:

Code:

---

if (ptr == 0)

---

I can assume the code is not written in C?

In windows

Code:

---

#include <windows.h>

---

In everything else

Code:

---

#define NULL 0

---

I see your point swoopy but you know what I meant. Sorry if I didn't elaborate enough.

>I see your point swoopy but you know what I meant. Sorry if I didn't elaborate enough.
Well, Bjarne Stroustrup indeed prefers 0. I've always liked NULL, so I can tell the variable is a pointer immediately. But I guess nullptr will soon be here, so the point will then be moot.

Quote:

---

In everything else

---

Actually, NULL is defined in <cstddef>, so we might as well include that standard header instead of defining NULL ourselves.

Quote:

---

Originally Posted by lruc

0 is c++:NULL is c.
It's as simple as that.

---

Is not.
NULL exists in both C and C++. What it is defined as is irrelevant.
The purpose of NULL hasn't changed in C++.