Thread: Anyone else think it's kinda weird...

  1. #16
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by CommonTater
    Need it made any plainer?
    The code plainly shows that you are wrong, but since you insist, let's look at the text of C99, which Pelles C is supposed to conform to:
    Quote Originally Posted by C99 Clause 6.3.2.3 Paragraph 3 (part)
    An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.
    Quote Originally Posted by C99 Clause 7.17 Paragraph 3 (part)
    The macros are
    Code:
    NULL
    which expands to an implementation-defined null pointer constant
    So, NULL is a null pointer constant. 0 is an "integer constant expression with the value 0". Therefore, a conforming standard library implementation may have:
    Code:
    #define NULL 0
    Clearly, your statement that "NULL isn't 0" does not always hold true.

    Next, you claim that "it's a pointer to 0", then you show us:
    Code:
    #define NULL  ((void *)0)
    Obviously, ((void*)0) is "an integer constant expression with the value 0 (...) cast to type void *". It is not a pointer to 0, whatever that is since one cannot directly take the address of an integer literal.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  2. #17
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Ok... are we all done nit picking now?

    Really... what do you think (void*)0 is? In any other context you would say void* is a pointer... why is that not so here?

  3. #18
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by CommonTater
    Ok... are we all done nit picking now?
    I would be done nit picking if you accept that your nit pick of Babkockdood's statement is wrong

    Quote Originally Posted by CommonTater
    Really... what do you think (void*)0 is?
    A null pointer constant. Since the type of the expression is void* (i.e., a pointer type), it is a null pointer.

    Quote Originally Posted by CommonTater
    In any other context you would say void* is a pointer... why is that not so here?
    Where did I say that void* is not a pointer type?
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  4. #19
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Quote Originally Posted by C99 Clause 6.3.2.3 Paragraph 3 (part)
    An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.
    An integer constant expression with the value 0 is clearly NOT a null pointer. It is only under certain circumstances. It is in fact because of this mess that we got the NULL macro.

    It bothers me that still today this whole issue is discussed as if it was only a matter of stylist convention, or aesthetic preference, when it clearly is not. This is a shortcoming of the programming language and honesty dictates we should treat it exactly like that.

    The only thing that is clear is that nothing is clear:
    • Null may be 0 depending on how it was defined.
    • 0 may not be a null pointer constant depending on how it is being used
    #define NULL 0 will not define a null pointer constant. We may pretend it will but we will often be required to cast NULL. However NULL only purpose in life is to take the place of a null pointer. Because of this, saying that NULL and 0 are the same thing is shortsighted and choosing to ignore the language limitations expressed in the standard.

    C++ does define NULL as being 0. But again, it does not define a null pointer. Just pretends it does, until anyone is forced to cast it or have to face logic or compilation errors. NULL is not 0. It cannot be under a type-safe language and because of that we have a dent in the standard. For C++, solutions like Meyers' nullptr idiom (and now about to move to C++0x) have been devised exactly to partially cover this problem.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  5. #20
    Registered User
    Join Date
    Jan 2010
    Posts
    412
    Going back on topic, the ato* functions are in my opinion examples of functions with weird/dumb return values, where 0 is returned both for failure and a successful conversion of "0"

  6. #21
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by laserlight View Post
    I would be done nit picking if you accept that your nit pick of Babkockdood's statement is wrong


    A null pointer constant. Since the type of the expression is void* (i.e., a pointer type), it is a null pointer.


    Where did I say that void* is not a pointer type?
    Well, if NULL is (void*)0 ... then it's a pointer.... either that or void* is not a pointer... Make up your mind.

  7. #22
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    5,108
    Going back on topic, the ato* functions are in my opinion examples of functions with weird/dumb return values, where 0 is returned both for failure and a successful conversion of "0"
    That has always bugged me too.

    Well, if NULL is (void*)0 ... then it's a pointer.... either that or void* is not a pointer... Make up your mind.
    Which of these code snippets contains a pointer to 1?

    Code:
    int * p = 1;
    Code:
    int * p;
    // ...
    *p = 1;
    Soma

  8. #23
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by Mario F.
    An integer constant expression with the value 0 is clearly NOT a null pointer. It is only under certain circumstances.
    I would say that it is never a null pointer, since the type of an integer constant expression is an integer type, not a pointer type.

    Quote Originally Posted by Mario F.
    #define NULL 0 will not define a null pointer constant.
    No, it does. I can agree that it is dumb that a pointer constant does not have pointer type, but that's that in C (and C++).

    Quote Originally Posted by Mario F.
    We may pretend it will but we will often be required to cast NULL. However NULL only purpose in life is to take the place of a null pointer. Because of this, saying that NULL and 0 are the same thing is shortsighted and choosing to ignore the language limitations expressed in the standard.
    I agree, but in the event that NULL is indeed defined to be 0, then they really are the same thing in both type and value. Saying otherwise is just ignoring the facts; admitting this leads to the acceptance of such solutions as nullptr in C++.

    Quote Originally Posted by _Mike
    Going back on topic, the ato* functions are in my opinion examples of functions with weird/dumb return values, where 0 is returned both for failure and a successful conversion of "0"
    Yeah. But then that is kind of fixed with the strto* functions, heh.

    Quote Originally Posted by CommonTater
    Well, if NULL is (void*)0 ... then it's a pointer.... either that or void* is not a pointer... Make up your mind.
    You should ask the C standards committee to make up their minds and make it such that NULL is always defined as ((void*)0) in the C standard library
    Oh, and see phantomotap's post #22.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  9. #24
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by laserlight View Post
    Oh, and see phantomotap's post #22.
    I don't read his crap.

  10. #25
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    2,158
    Code:
    /* This is a pointer to zero. */
    long int number = 0;
    long int* pointer = &number;

    Code:
    /* This is a null pointer. */
    long int* pointer = NULL;

    This is why we say, a null pointer isn't a pointer to zero. Because, as you can see, these codes do very different things.
    I'm open to being shown how this isn't the case, but I fail to see how you could possibly disagree with the definitions in these snippets.

  11. #26
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Quote Originally Posted by Yarin View Post
    Code:
    /* This is a pointer to zero. */
    long int number = 0;
    long int* pointer = &number;
    No it isn't. It's a pointer to an integer, and that integer's value is zero. It's not a pointer to zero.
    Quote Originally Posted by Yarin View Post
    I fail to see how you could possibly disagree with the definitions in these snippets.
    I just showed you. That's not a pointer to zero. It's a pointer to an integer. You don't say that a pointer is a "pointer to <whatever value the variable holds>", you say it's a "pointer to <type>".

    And while you might say "it's a NULL pointer", you never say "it's a five pointer", because that would be stupid.


    Quzah.
    Last edited by quzah; 07-27-2011 at 05:08 PM.
    Hope is the first step on the road to disappointment.

  12. #27
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    2,158
    Quote Originally Posted by quzah View Post
    No it isn't. It's a pointer to an integer, and that integer's value is zero. It's not a pointer to zero.
    In a more correct sense, that's absolutely right, but...
    Quote Originally Posted by quzah View Post
    You don't say that a pointer is a "pointer to <whatever value the variable holds>", you say it's a "pointer to <type>".
    This is wrong. You _do_ say "pointer to <value>", as well as, "pointer to <type>". While this may not be correct in the most technical sense. It's what people say, because it's easier, and to say it in the long form is redundant considering you know what one means when they say that anyway.

    But then... if you want to get all technically correct, then really, down the same line of thinking, saying "pointer to <type>" is also wrong. It's a "pointer to <said> location in memory".
    Quote Originally Posted by quzah View Post
    And while you might say "it's a NULL pointer", you never say "it's a five pointer", because that would be stupid.
    This is explained by the fact that a "null pointer" is intended to be understood as _not_ pointing to an address, in essence _not_ pointing somewhere, or pointing nowhere, all in all, not functioning as a pointer is generally expected to, ergo a "null pointer". It's for this reason we don't say it's pointing to zero.
    While a "five pointer" (that being (void*)5), is understood to function... as a pointer, that is point to somewhere, so yeah, of course calling it a "five pointer" wouldn't make sense.

  13. #28
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by Yarin
    This is wrong. You _do_ say "pointer to <value>", as well as, "pointer to <type>". While this may not be correct in the most technical sense. It's what people say, because it's easier, and to say it in the long form is redundant considering you know what one means when they say that anyway.
    Yes, I would accept "pointer to <value>" as a colloquial expression for "pointer to an object with value <value>".

    Quote Originally Posted by Yarin
    But then... if you want to get all technically correct, then really, down the same line of thinking, saying "pointer to <type>" is also wrong. It's a "pointer to <said> location in memory"
    No, merely talking about a location in memory is incomplete. A pointer's value is an address, but the pointer itself has a type, derived from the type of an object that the pointer would point to.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  14. #29
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    >> This is wrong. You _do_ say "pointer to <value>", as well as, "pointer to <type>". While this may not be correct in the most technical sense. It's what people say, because it's easier.

    Convenience is no substitute for exactness. You don't program in spoken language. Especially when discussing programming concepts in what concerns their details.

    >> But then... if you want to get all technically correct, then really, down the same line of thinking, saying "pointer to <type>" is also wrong. It's a "pointer to <said> location in memory".

    No. A pointer is of type T*. It's T* that will give memory structure and meaning. A pointer points to T and may or may not hold a memory location.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  15. #30
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    I'm not convinced. Just because CommonTater says "pointer to <value>" doesn't mean everyone else does. CommonTater makes it a point to tell everyone he is different from the average programmer here.

    I'm used to people saying "point to" when they are talking about objects.

    When people are talking about values, I'm used to people saying "the pointer's value" with value being the key word.

    But we all understood what CommonTater meant, so it didn't matter in the end! We all just like to argue. Maybe he should see it that way.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. kinda new need help
    By drkylec in forum C++ Programming
    Replies: 1
    Last Post: 03-09-2011, 03:30 PM
  2. kinda aggrivating me
    By guyfromfl in forum A Brief History of Cprogramming.com
    Replies: 33
    Last Post: 03-31-2008, 10:54 AM
  3. I'm kinda new to C++
    By DeanDemon in forum C++ Programming
    Replies: 9
    Last Post: 12-01-2002, 12:52 AM