Jump to content
  • Advertisement
Sign in to follow this  
ehmdjii

when are pointers true or false

This topic is 4898 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Nathan Baum: Of course. I'm not sure why I didn't think to look up 'if'. Still, IMO it is interesting that "if((int)Pointer){}"(or even "if((intptr_t)Pointer){}") is apparently implementation dependent, while "if(Pointer){}" is not.

Share this post


Link to post
Share on other sites
Advertisement
IIRC, NULL is not guaranteed to be zero on all systems. However, it is guaranteed to always be false, and consequently all compiler writers in their right minds have made NULL = 0.

Share this post


Link to post
Share on other sites
I would prefer to see if(pointer != NULL) vs if(pointer). The pointer isn't truly a boolean - it is easier to see what you mean if you specify a conditional. Just my opinion...

Share this post


Link to post
Share on other sites
I prefer to see if(pointer) because it is idiomatic:


Data* data = NULL;
// ...
// sekret codes! will the pointer be assigned or not? :o
// ...
if (data) { // "if we have data"
data.doSomething();
}


But it's also nicer to avoid nulls where possible, especially via the use of a Null Object pattern where it makes sense - because extra if's are icky in their own way too.

Share this post


Link to post
Share on other sites
In C++ one is generally suggested to just use 0 anyways, since C headers like to set NULL to ((void*)0), which doesn't work properly in C++ ( because there's no implicit conversion to T* from void*).

...at least until the nullptr proposal gets accepted ;)

Share this post


Link to post
Share on other sites
Quote:
Original post by ehmdjii
thank you all!

so when i leave the pointer uninitialized like in the above example, it will still evaluate to true, cause it points to random memory?




No, it will randomly be either true or false. Although the random value needs to be 0 for it to evaluate to false, it is very common for this to happen with variables allocated on the stack. Always initialise your variables, unless you have a very good reason not to.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Zahlman

Data* data = NULL;
...
if (data) { // "if we have data"
data.doSomething();



There should be a "->" instead of a "." since it's a pointer.

Share this post


Link to post
Share on other sites
Quote:
Original post by Extrarius
Nathan Baum: Of course. I'm not sure why I didn't think to look up 'if'. Still, IMO it is interesting that "if((int)Pointer){}"(or even "if((intptr_t)Pointer){}") is apparently implementation dependent, while "if(Pointer){}" is not.

Well, it's because C and C++ are engaging in a bit of doublethink with regards to '0'.

0 is both an integer constant, and the null pointer constant. C++ sensibly doesn't define conditional expressions in terms of comparison to 0, but neither language is prepared to have distinct syntax for a null pointer constant.

Additionally, there's no rule that says the null pointer has to point at the first byte of memory. The null pointer might point at some other location. It only needs to be distinct from any other pointer. If you're allowed to have a non-null pointer which points at the first byte, then obviously the null pointer can't point there.

On Intel architectures at least, location zero is a real memory location and contains the start of the interrupt table, which you'd have to be able to access if you were writing a kernel, say.

Of course, for efficiency reasons it's better to use a zero, since comparisons to it can be done very quickly on most architectures. You'd probably use assembly for access the interrupt table, where you'd just have to know whether a 0 was a null pointer or a pointer to the first byte of memory.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!