• NULL versus 0

    From dashley@gmail.com@21:1/5 to All on Sat Sep 25 11:03:30 2021
    I'm reading "Sams Teach Yourself C++ in One Hour a Day (6th Edition)".

    (I'm already an expert-level C programmer, learning C++. I just say that as notice that you don't need to overexplain.)

    In the examples in the book, they assign pointers to 0, typically at definition, i.e.

    int *pInt = 0;

    Nothing inherently wrong with that, but in C, it would be more traditional to use NULL. I believe the value assigned is going to be the same, whether 0 or NULL is used.

    Is one style preferred over the other in C++? Why?

    Thanks.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paavo Helde@21:1/5 to All on Sat Sep 25 21:20:00 2021
    25.09.2021 21:03 das...@gmail.com kirjutas:
    I'm reading "Sams Teach Yourself C++ in One Hour a Day (6th Edition)".

    (I'm already an expert-level C programmer, learning C++. I just say that as notice that you don't need to overexplain.)

    In the examples in the book, they assign pointers to 0, typically at definition, i.e.

    int *pInt = 0;

    Nothing inherently wrong with that, but in C, it would be more traditional to use NULL. I believe the value assigned is going to be the same, whether 0 or NULL is used.

    Is one style preferred over the other in C++? Why?

    In C++ (unlike C), NULL is a macro defined to 0, so there is no
    difference. There are special rules about converting literal 0 to
    pointer values. However, this was a kind of hack which did not work so
    well after all, so C++11 introduced a new special keyword for a null
    pointer. So the current preferred style is:

    int *pInt = nullptr;

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paavo Helde@21:1/5 to All on Sat Sep 25 21:32:33 2021
    25.09.2021 21:20 Paavo Helde kirjutas:
    25.09.2021 21:03 das...@gmail.com kirjutas:
    I'm reading "Sams Teach Yourself C++ in One Hour a Day (6th Edition)".

    (I'm already an expert-level C programmer, learning C++.  I just say
    that as notice that you don't need to overexplain.)

    In the examples in the book, they assign pointers to 0,

    Oh, and if this book predates C++11 (i.e. 2011), be aware that some
    content is out-dated and it does not cover the myriad of new
    enhancements introduced by C++11. You might want to use a newer book.

    C++11 is quite essential for using C++ effectively nowadays. Later
    additions have been smaller and more specialized, so can be postponed
    for a while.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From dashley@gmail.com@21:1/5 to All on Sat Sep 25 12:08:15 2021
    Oh, and if this book predates C++11 (i.e. 2011), be aware that some
    content is out-dated and it does not cover the myriad of new
    enhancements introduced by C++11. You might want to use a newer book.

    C++11 is quite essential for using C++ effectively nowadays. Later
    additions have been smaller and more specialized, so can be postponed
    for a while.

    Thanks for the heads up! You were correct. Amazon tells me that the 6th edition was released in 2008, and I purchased it in 2011. (It seems like only yesterday LOL.)

    I spent $20.49 and grabbed the latest edition (8th edition), which claims to cover C++ 2011 and C++ 2014. Since I'm only in Chapter 8, re-skimming for changes should be easy and then I can continue.

    TBH, it would not have made a practical difference. I'm actually working on a Blackjack simulation program (and writing a book) to evaluate card counting strategies, so that I can drink and gamble more. I figured it would be a good chance to learn and
    get comfortable with C++ (although I could do it in C). For that type of program (mildly complex simulation, essentially numerical), advanced features of the language probably would not come into play.

    As an aside, SOMEBODY will point out that there are lots of Blackjack books on the market, and what more could I want to know. Just to satisfy the curious, here are my reasons:

    a)Blackjack authors are, on average, bad mathematicians. I don't trust what they publish. I would prefer to double-check.

    b)I would prefer to know the first decimal point after some true count boundaries. For example, with hi-lo, it is typical to take the insurance bet at 3 or above. Is it really 3? Or is it 3.2? I can do arithmetic in my head well enough to want to
    know precisely.

    c)No book I'm aware of covers the mathematical basis of camouflage plays (and it is mathematical). The goal is to do something that appears as bizarre as possible but that has a very small negative impact on expected value, so as to keep the dealer and
    pit bosses convinced that you aren't right in the head rather than being a skilled card counter. The notion of what you can do that appears bizarre but is not costly is mathematical.

    d)I would like to maximize total return, which also involves counting against side bets, if possible. So, the "best" counting strategy at a given game with side bets may not be the best strategy for pure Blackjack. Again, no book I'm aware of looks at
    how best to count against the TOTAL game, including side bets.

    So, to cut off the obvious feedback I would otherwise receive, .... no, I'm not reinventing the wheel.

    Thanks for the heads up on upgrading my book!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Branimir Maksimovic@21:1/5 to das...@gmail.com on Sat Sep 25 18:16:00 2021
    On 2021-09-25, das...@gmail.com <dashley@gmail.com> wrote:
    I'm reading "Sams Teach Yourself C++ in One Hour a Day (6th Edition)".

    (I'm already an expert-level C programmer, learning C++. I just say that as notice that you don't need to overexplain.)

    In the examples in the book, they assign pointers to 0, typically at definition, i.e.

    int *pInt = 0;

    Nothing inherently wrong with that, but in C, it would be more traditional to use NULL. I believe the value assigned is going to be the same, whether 0 or NULL is used.

    Is one style preferred over the other in C++? Why?


    There were problems between using 0 as *integer* or *pointer*, now
    we have nullptr to differentitate.

    Thanks.



    --

    7-77-777
    Evil Sinner!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From see.my.homepage@gmail.com@21:1/5 to All on Sat Sep 25 13:05:51 2021
    int *pInt = 0;

    Nothing inherently wrong with that, but in C, it would be more traditional to use NULL.

    It would be more traditional in C++, as well. Even though the actual definition means it's the same for the compiler, there is a difference for the human reader. NULL stands out in the code and immediately draws attention to its intended meaning as a
    pointer, whereas literal 0 is a number. I certainly prefer NULL over 0 in such uses.

    Is one style preferred over the other in C++? Why?

    Things get more interesting with nullptr vs. NULL (since C++11), but I have to admit I'm not much excited about nullptr. NULL still draws attention more and I appreciate it for exactly this reason. Does it cause problems? I don't deny any horror story,
    but I certainly don't have any to share myself, so nullptr did not solve any measurable problem for me. I still write NULL in new code (and that usually applies to calling 3rd-party libraries) and I don't feel bad about it. You might find convincing
    arguments for the contrary, too. I believe it will stay as subjective choice forever.

    --
    Maciej Sobczak * http://www.inspirel.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Kuyper@21:1/5 to das...@gmail.com on Sat Sep 25 17:36:27 2021
    On 9/25/21 2:03 PM, das...@gmail.com wrote:
    I'm reading "Sams Teach Yourself C++ in One Hour a Day (6th Edition)".

    (I'm already an expert-level C programmer, learning C++. I just say that as notice that you don't need to overexplain.)

    In the examples in the book, they assign pointers to 0, typically at definition, i.e.

    int *pInt = 0;

    Nothing inherently wrong with that, but in C, it would be more traditional to use NULL. I believe the value assigned is going to be the same, whether 0 or NULL is used.

    Is one style preferred over the other in C++? Why?

    In C, NULL can be defined as (void*)0, which is safer than 0, because it
    cannot be accidentally used in arithmetic contexts, which is a good
    reason to prefer NULL.

    In C++, NULL is not permitted to expand to (void*)0, but it can be
    defined as nullptr, which is not only safer than 0, but also is safer
    than (void*)0, so NULL should be preferred in C++, too. However, as a
    general rule explicit use of nullptr would be even better, because NULL
    could simply be defined as 0.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jorgen Grahn@21:1/5 to see.my....@gmail.com on Sun Sep 26 06:58:15 2021
    On Sat, 2021-09-25, see.my....@gmail.com wrote:
    int *pInt = 0;

    Nothing inherently wrong with that, but in C, it would be more
    traditional to use NULL.

    It would be more traditional in C++, as well.

    Opinions varied. Before nullptr, I always used NULL in C and 0 in
    C++. IIRC using 0 was a common recommendation here, too, for whatever
    reason.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Branimir Maksimovic@21:1/5 to Jorgen Grahn on Sun Sep 26 07:47:18 2021
    On 2021-09-26, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
    On Sat, 2021-09-25, see.my....@gmail.com wrote:
    int *pInt = 0;

    Nothing inherently wrong with that, but in C, it would be more
    traditional to use NULL.

    It would be more traditional in C++, as well.

    Opinions varied. Before nullptr, I always used NULL in C and 0 in
    C++. IIRC using 0 was a common recommendation here, too, for whatever reason.

    #define NULL (void*)0
    simple, problem is that in C++, one have to cast from void
    and that does not works, and this is BuG in C++.


    --

    7-77-777
    Evil Sinner!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keith Thompson@21:1/5 to Branimir Maksimovic on Sun Sep 26 02:15:13 2021
    Branimir Maksimovic <branimir.maksimovic@gmail.com> writes:
    On 2021-09-26, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
    On Sat, 2021-09-25, see.my....@gmail.com wrote:
    int *pInt = 0;

    Nothing inherently wrong with that, but in C, it would be more
    traditional to use NULL.

    It would be more traditional in C++, as well.

    Opinions varied. Before nullptr, I always used NULL in C and 0 in
    C++. IIRC using 0 was a common recommendation here, too, for whatever
    reason.

    #define NULL (void*)0
    simple, problem is that in C++, one have to cast from void
    and that does not works, and this is BuG in C++.

    That's not a valid definition of NULL in either C or C++.

    In C or C++, the definition has to be parenthesized to avoid parsing
    errors in some contexts;

    #define NULL ((void*0)

    I'm not sure what you mean by "this is BuG in C++". A C++
    implementation that defined NULL that way would be non-conforming.

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    Working, but not speaking, for Philips
    void Void(void) { Void(); } /* The recursive call of the void */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Branimir Maksimovic@21:1/5 to Keith Thompson on Sun Sep 26 09:38:33 2021
    On 2021-09-26, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

    #define NULL (void*)0
    simple, problem is that in C++, one have to cast from void
    and that does not works, and this is BuG in C++.

    That's not a valid definition of NULL in either C or C++.

    In C or C++, the definition has to be parenthesized to avoid parsing
    errors in some contexts;

    #define NULL ((void*0)

    I'm not sure what you mean by "this is BuG in C++". A C++
    implementation that defined NULL that way would be non-conforming.

    Exactly, that is why it is Bug.
    Thanks for correction, BTW.

    --

    7-77-777
    Evil Sinner!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keith Thompson@21:1/5 to Jorgen Grahn on Sun Sep 26 02:17:15 2021
    Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
    On Sat, 2021-09-25, see.my....@gmail.com wrote:
    int *pInt = 0;

    Nothing inherently wrong with that, but in C, it would be more
    traditional to use NULL.

    It would be more traditional in C++, as well.

    Opinions varied. Before nullptr, I always used NULL in C and 0 in
    C++. IIRC using 0 was a common recommendation here, too, for whatever reason.

    As I recall, Stroustrup's books used 0 when a null pointer constant was required, and that was probably the origin of the (pre-nullptr)
    convention to use 0 in C++ while NULL is more widely recommended in C.

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    Working, but not speaking, for Philips
    void Void(void) { Void(); } /* The recursive call of the void */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bo Persson@21:1/5 to Branimir Maksimovic on Sun Sep 26 13:54:36 2021
    On 2021-09-26 at 09:47, Branimir Maksimovic wrote:
    On 2021-09-26, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
    On Sat, 2021-09-25, see.my....@gmail.com wrote:
    int *pInt = 0;

    Nothing inherently wrong with that, but in C, it would be more
    traditional to use NULL.

    It would be more traditional in C++, as well.

    Opinions varied. Before nullptr, I always used NULL in C and 0 in
    C++. IIRC using 0 was a common recommendation here, too, for whatever
    reason.

    #define NULL (void*)0
    simple, problem is that in C++, one have to cast from void
    and that does not works, and this is BuG in C++.


    It is not a bug when it is done very much on purpose.

    Stroustrup says:

    "A pointer to any type of object can be assigned to a variable of type
    void*, a void* can be assigned to another void*, void* can be compared
    for equality and inequality, and a void* can be explicitly converted to
    another type. Other operations would be unsafe because the compiler
    cannot know what kind of object is really pointed to. Consequently,
    other operations result in compile-time errors."

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HorseyWorsey@the_stables.com@21:1/5 to Jorgen Grahn on Sun Sep 26 14:20:33 2021
    On 26 Sep 2021 06:58:15 GMT
    Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
    On Sat, 2021-09-25, see.my....@gmail.com wrote:
    int *pInt = 0;

    Nothing inherently wrong with that, but in C, it would be more
    traditional to use NULL.

    It would be more traditional in C++, as well.

    Opinions varied. Before nullptr, I always used NULL in C and 0 in
    C++. IIRC using 0 was a common recommendation here, too, for whatever >reason.

    It still use NULL instead of nullptr because its a lot more obvious when
    speed reading code.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keith Thompson@21:1/5 to Branimir Maksimovic on Sun Sep 26 15:03:42 2021
    Branimir Maksimovic <branimir.maksimovic@gmail.com> writes:
    On 2021-09-26, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    #define NULL (void*)0
    simple, problem is that in C++, one have to cast from void
    and that does not works, and this is BuG in C++.

    That's not a valid definition of NULL in either C or C++.

    In C or C++, the definition has to be parenthesized to avoid parsing
    errors in some contexts;

    #define NULL ((void*0)

    I'm not sure what you mean by "this is BuG in C++". A C++
    implementation that defined NULL that way would be non-conforming.

    Exactly, that is why it is Bug.
    Thanks for correction, BTW.

    To be clear, you're saying that if any C++ implementation actually
    defined NULL that way, it would be a bug in that implementation.
    That's true, but I'm not aware of any implementation that actually
    has that hypothetical bug. It can require some trivial extra work
    for an implementation that shares headers between C and C++, but
    implementers are well aware of the issue.

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    Working, but not speaking, for Philips
    void Void(void) { Void(); } /* The recursive call of the void */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keith Thompson@21:1/5 to Bo Persson on Sun Sep 26 15:17:19 2021
    Bo Persson <bo@bo-persson.se> writes:
    On 2021-09-26 at 09:47, Branimir Maksimovic wrote:
    On 2021-09-26, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
    On Sat, 2021-09-25, see.my....@gmail.com wrote:
    int *pInt = 0;

    Nothing inherently wrong with that, but in C, it would be more
    traditional to use NULL.

    It would be more traditional in C++, as well.

    Opinions varied. Before nullptr, I always used NULL in C and 0 in
    C++. IIRC using 0 was a common recommendation here, too, for whatever
    reason.
    #define NULL (void*)0
    simple, problem is that in C++, one have to cast from void
    and that does not works, and this is BuG in C++.

    It is not a bug when it is done very much on purpose.

    Stroustrup says:

    "A pointer to any type of object can be assigned to a variable of type
    void*, a void* can be assigned to another void*, void* can be compared
    for equality and inequality, and a void* can be explicitly converted
    to another type. Other operations would be unsafe because the compiler
    cannot know what kind of object is really pointed to. Consequently,
    other operations result in compile-time errors."

    "The C++ Programming Language", 4th edition, section 7.2.1.

    As Stroustrup says, converting from void* to another pointer type
    requires an explicit conversion, but converting NULL to any pointer
    type does not. (void*)0 is a null pointer constant in C, but not in C++.

    This:
    int *p;
    p = (void*)0;
    is invalid in C++, but this:
    int *p;
    p = NULL;
    is valid. Because of that, a C++ implementation that defines NULL as
    either (void*)0 or ((void*)0) is non-conforming. (It's unlikely that
    any actual C++ implementations make that mistake.)

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    Working, but not speaking, for Philips
    void Void(void) { Void(); } /* The recursive call of the void */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris M. Thomasson@21:1/5 to das...@gmail.com on Sun Sep 26 23:05:16 2021
    On 9/25/2021 11:03 AM, das...@gmail.com wrote:
    I'm reading "Sams Teach Yourself C++ in One Hour a Day (6th Edition)".

    (I'm already an expert-level C programmer, learning C++. I just say that as notice that you don't need to overexplain.)

    In the examples in the book, they assign pointers to 0, typically at definition, i.e.

    int *pInt = 0;

    Nothing inherently wrong with that, but in C, it would be more traditional to use NULL. I believe the value assigned is going to be the same, whether 0 or NULL is used.

    Is one style preferred over the other in C++? Why?

    Thanks.


    void* foo = 0;
    void* foobar = NULL;
    void* foobarCpp = nullptr;

    Means foo == foobar == foobarCpp.

    So, they should all be the same. Well, an impl can define these things
    to mean a "null" pointer on their system, so to speak. Magic! nullptr
    might mean something odd, and exotic under the hood... So does 0 wrt pointers... ;^)

    _____________________________
    #include <iostream>

    int main()
    {
    void* foo = 0;
    void* foobar = NULL;
    void* foobarCpp = nullptr;

    std::cout << "foo = " << foo << "\n";
    std::cout << "foobar = " << foobar << "\n";
    std::cout << "foobarCpp = " << foobarCpp << "\n";

    return 0;
    }
    _____________________________

    Well, shit... Whats your output?
    Can you even compile the damn thing?

    ;^)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Juha Nieminen@21:1/5 to Paavo Helde on Mon Sep 27 05:47:02 2021
    Paavo Helde <myfirstname@osa.pri.ee> wrote:
    In C++ (unlike C), NULL is a macro defined to 0, so there is no
    difference.

    Actually, many standard library implementations define NULL to be
    nullptr (if we are in C++11 or newer).

    (I haven't checked the standard, but this tells me that the standard does
    not mandate NULL to be defined as 0.)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris M. Thomasson@21:1/5 to Bo Persson on Sun Sep 26 23:37:17 2021
    On 9/26/2021 11:32 PM, Bo Persson wrote:
    On 2021-09-27 at 07:47, Juha Nieminen wrote:
    Paavo Helde <myfirstname@osa.pri.ee> wrote:
    In C++ (unlike C), NULL is a macro defined to 0, so there is no
    difference.

    Actually, many standard library implementations define NULL to be
    nullptr (if we are in C++11 or newer).

    (I haven't checked the standard, but this tells me that the standard does
    not mandate NULL to be defined as 0.)


    It just says

    "The macro NULL is an implementation-defined null pointer constant."

    And then a footnote saying that 0 is one possibility, but (void*)0 is not.

    OT comment: For some damn odd reason; thinking of this subject makes me
    think of the following song:

    https://youtu.be/y3hf0T4qpYg

    Strange!

    http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher= e320776c84d666caf19b80ac7925f3d9e30ab3d99e0ab58d634535629abb3d2f4b8a981dc0fbd9024aca3d2a2b29de38323340cf7e700b8599ddfac7d6d5972d0a2e8b8e9d751ecf0ea7a25e9394a86496ab208cb5b846f01bdff721feb48f8ece892344689b3d8db8bb39c3b21dfe4aad2f65608c0ef1ca3737a23b63c09ba
    2b0dad9ccd9a81cbf3a53a480bc0a55f9be590f6e021c787972bddce2f249e45137f75884f82bc74fa8115f0339b4c1515b55dfefd1f8322f16de06c50b5e3b7381f4d044ad9cdfad661d9c677e63a5c440ef9ac49c3a78c5397fe4ee2039d79cc7d790fe11036f99b6a3e9b8a6c738a84deccdf24d1277cbc081ae42398979
    a04346e34e6f3a135cdf6a3cf78b771a7bf052564c27e6767ad769141be938f1c35dff31c353311989339523a3dad8a8530e2301303329aa050ce085a6135338f3bdcef27485f2843df96ce01cee17b17ef5db63b621392c7dc08487add5c382d40199a67b6978f83650e3c586d67207731ed42b954b433ef6ff8f84b06456b
    9394eb610b116cfefe266a185


    decrypts to the following plaintext using the default key: _____________________________
    #include <iostream>

    int main()
    {
    void* foo = 0;
    void* foobar = NULL;
    void* foobarCpp = nullptr;

    std::cout << "foo = " << foo << "\n";
    std::cout << "foobar = " << foobar << "\n";
    std::cout << "foobarCpp = " << foobarCpp << "\n";

    return 0;
    }
    _____________________________

    ;^)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bo Persson@21:1/5 to Juha Nieminen on Mon Sep 27 08:32:37 2021
    On 2021-09-27 at 07:47, Juha Nieminen wrote:
    Paavo Helde <myfirstname@osa.pri.ee> wrote:
    In C++ (unlike C), NULL is a macro defined to 0, so there is no
    difference.

    Actually, many standard library implementations define NULL to be
    nullptr (if we are in C++11 or newer).

    (I haven't checked the standard, but this tells me that the standard does
    not mandate NULL to be defined as 0.)


    It just says

    "The macro NULL is an implementation-defined null pointer constant."

    And then a footnote saying that 0 is one possibility, but (void*)0 is not.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alf P. Steinbach@21:1/5 to Bo Persson on Mon Sep 27 10:32:42 2021
    On 27 Sep 2021 08:32, Bo Persson wrote:
    On 2021-09-27 at 07:47, Juha Nieminen wrote:
    Paavo Helde <myfirstname@osa.pri.ee> wrote:
    In C++ (unlike C), NULL is a macro defined to 0, so there is no
    difference.

    Actually, many standard library implementations define NULL to be
    nullptr (if we are in C++11 or newer).

    (I haven't checked the standard, but this tells me that the standard does
    not mandate NULL to be defined as 0.)


    It just says

    "The macro NULL is an implementation-defined null pointer constant."

    And then a footnote saying that 0 is one possibility, but (void*)0 is not.

    C++17 §7.11/1:
    ❝A /null pointer constant/ is an integer literal with value zero or a
    prvalue of type `std::nullptr_t`.❞

    As I recall the insistence on a null pointer constant being a literal
    was introduced in C++11; the C++03 definition was

    C++03 §4.10/1:
    ❝A /null pointer constant/ is an integral constant expression rvalue of integer type that evaluates to zero.❞

    A subtle but perhaps important change.


    - Alf

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Kuyper@21:1/5 to Juha Nieminen on Mon Sep 27 15:03:14 2021
    On 9/27/21 1:47 AM, Juha Nieminen wrote:
    Paavo Helde <myfirstname@osa.pri.ee> wrote:
    In C++ (unlike C), NULL is a macro defined to 0, so there is no
    difference.

    Actually, many standard library implementations define NULL to be
    nullptr (if we are in C++11 or newer).

    (I haven't checked the standard, but this tells me that the standard does
    not mandate NULL to be defined as 0.)

    The mandate is quite clear:

    "The macro NULL is an implementation-defined null pointer constant."
    (17.2p3).

    Note that "null pointer constant" has a different definition in C++ than
    in C, and when compiling using C++, NULL must have a definition that
    meets C++ requirements rather than C requirements. In particular, that
    means that NULL can expand to "a prvalue of type std::nullptr_t." (7.3.11p1)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keith Thompson@21:1/5 to Alf P. Steinbach on Mon Sep 27 11:32:41 2021
    "Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
    On 27 Sep 2021 08:32, Bo Persson wrote:
    On 2021-09-27 at 07:47, Juha Nieminen wrote:
    Paavo Helde <myfirstname@osa.pri.ee> wrote:
    In C++ (unlike C), NULL is a macro defined to 0, so there is no
    difference.

    Actually, many standard library implementations define NULL to be
    nullptr (if we are in C++11 or newer).

    (I haven't checked the standard, but this tells me that the standard does >>> not mandate NULL to be defined as 0.)

    It just says
    "The macro NULL is an implementation-defined null pointer constant."
    And then a footnote saying that 0 is one possibility, but (void*)0
    is not.

    C++17 §7.11/1:
    ❝A /null pointer constant/ is an integer literal with value zero or a prvalue of type `std::nullptr_t`.❞

    As I recall the insistence on a null pointer constant being a literal
    was introduced in C++11; the C++03 definition was

    C++03 §4.10/1:
    ❝A /null pointer constant/ is an integral constant expression rvalue
    of integer type that evaluates to zero.❞

    A subtle but perhaps important change.

    Perhaps subtle, but I don't think it's all that important. It means
    that (2-2) is a null pointer constant in C++03 but not in C++17 -- but I
    can't think of any good reason to use (2-2) as a null pointer constant
    outside of deliberately contrived code.

    Of course the addition of `std::nullptr_t` is important.

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    Working, but not speaking, for Philips
    void Void(void) { Void(); } /* The recursive call of the void */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Branimir Maksimovic@21:1/5 to Bo Persson on Wed Sep 29 02:26:57 2021
    On 2021-09-26, Bo Persson <bo@bo-persson.se> wrote:
    On 2021-09-26 at 09:47, Branimir Maksimovic wrote:
    On 2021-09-26, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
    On Sat, 2021-09-25, see.my....@gmail.com wrote:
    int *pInt = 0;

    Nothing inherently wrong with that, but in C, it would be more
    traditional to use NULL.

    It would be more traditional in C++, as well.

    Opinions varied. Before nullptr, I always used NULL in C and 0 in
    C++. IIRC using 0 was a common recommendation here, too, for whatever
    reason.

    #define NULL (void*)0
    simple, problem is that in C++, one have to cast from void
    and that does not works, and this is BuG in C++.


    It is not a bug when it is done very much on purpose.

    Stroustrup says:

    "A pointer to any type of object can be assigned to a variable of type
    void*, a void* can be assigned to another void*, void* can be compared
    for equality and inequality, and a void* can be explicitly converted to another type. Other operations would be unsafe because the compiler
    cannot know what kind of object is really pointed to. Consequently,
    other operations result in compile-time errors."



    Problem is that you can convert to unknown type, but compiler doesn't
    just converto to enyother type. This is simply pointless as compiler
    cannot possibly know what is unknown type, cast or not :P
    Let's take *any* implicit conversion then, like new languages DO :P


    --

    7-77-777
    Evil Sinner!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Branimir Maksimovic@21:1/5 to Keith Thompson on Wed Sep 29 02:29:00 2021
    On 2021-09-26, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    Branimir Maksimovic <branimir.maksimovic@gmail.com> writes:
    On 2021-09-26, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    #define NULL (void*)0
    simple, problem is that in C++, one have to cast from void
    and that does not works, and this is BuG in C++.

    That's not a valid definition of NULL in either C or C++.

    In C or C++, the definition has to be parenthesized to avoid parsing
    errors in some contexts;

    #define NULL ((void*0)

    I'm not sure what you mean by "this is BuG in C++". A C++
    implementation that defined NULL that way would be non-conforming.

    Exactly, that is why it is Bug.
    Thanks for correction, BTW.

    To be clear, you're saying that if any C++ implementation actually
    defined NULL that way, it would be a bug in that implementation.
    That's true, but I'm not aware of any implementation that actually
    has that hypothetical bug. It can require some trivial extra work
    for an implementation that shares headers between C and C++, but
    implementers are well aware of the issue.

    We have problem off overoading resolution then with constant zero.
    Still, despite nullptr. You can accidentally mean 0 the integer
    and have overload with pointer argument, and hav COMPILER BUG.
    This should be corrected in future standard...

    --

    7-77-777
    Evil Sinner!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keith Thompson@21:1/5 to Branimir Maksimovic on Tue Sep 28 20:34:51 2021
    Branimir Maksimovic <branimir.maksimovic@gmail.com> writes:
    On 2021-09-26, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    Branimir Maksimovic <branimir.maksimovic@gmail.com> writes:
    On 2021-09-26, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    #define NULL (void*)0
    simple, problem is that in C++, one have to cast from void
    and that does not works, and this is BuG in C++.

    That's not a valid definition of NULL in either C or C++.

    In C or C++, the definition has to be parenthesized to avoid parsing
    errors in some contexts;

    #define NULL ((void*0)

    I'm not sure what you mean by "this is BuG in C++". A C++
    implementation that defined NULL that way would be non-conforming.

    Exactly, that is why it is Bug.
    Thanks for correction, BTW.

    To be clear, you're saying that if any C++ implementation actually
    defined NULL that way, it would be a bug in that implementation.
    That's true, but I'm not aware of any implementation that actually
    has that hypothetical bug. It can require some trivial extra work
    for an implementation that shares headers between C and C++, but
    implementers are well aware of the issue.

    We have problem off overoading resolution then with constant zero.
    Still, despite nullptr. You can accidentally mean 0 the integer
    and have overload with pointer argument, and hav COMPILER BUG.
    This should be corrected in future standard...

    I don't know what "COMPILER BUG" you're talking about.

    Using 0 as a null pointer constant in the presence of overloaded
    functions can lead to a *programming* bug. I'm not aware of any C++
    compiler that has a bug in this area (i.e., handles it in a way that's inconsistent with what the language requires).

    That kind of programming bug can be avoided by using nullptr rather than
    0 (something that wasn't possible before C++11).

    If you're suggesting changing the language so that 0 is no longer a null pointer constant, that would break tons of existing code.

    Programming bugs, compiler bugs, and language bugs are three very
    different things.

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    Working, but not speaking, for Philips
    void Void(void) { Void(); } /* The recursive call of the void */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Brown@21:1/5 to Keith Thompson on Wed Sep 29 08:52:36 2021
    On 29/09/2021 05:34, Keith Thompson wrote:
    Branimir Maksimovic <branimir.maksimovic@gmail.com> writes:
    On 2021-09-26, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    Branimir Maksimovic <branimir.maksimovic@gmail.com> writes:
    On 2021-09-26, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    #define NULL (void*)0
    simple, problem is that in C++, one have to cast from void
    and that does not works, and this is BuG in C++.

    That's not a valid definition of NULL in either C or C++.

    In C or C++, the definition has to be parenthesized to avoid parsing >>>>> errors in some contexts;

    #define NULL ((void*0)

    I'm not sure what you mean by "this is BuG in C++". A C++
    implementation that defined NULL that way would be non-conforming.

    Exactly, that is why it is Bug.
    Thanks for correction, BTW.

    To be clear, you're saying that if any C++ implementation actually
    defined NULL that way, it would be a bug in that implementation.
    That's true, but I'm not aware of any implementation that actually
    has that hypothetical bug. It can require some trivial extra work
    for an implementation that shares headers between C and C++, but
    implementers are well aware of the issue.

    We have problem off overoading resolution then with constant zero.
    Still, despite nullptr. You can accidentally mean 0 the integer
    and have overload with pointer argument, and hav COMPILER BUG.
    This should be corrected in future standard...

    I don't know what "COMPILER BUG" you're talking about.

    Using 0 as a null pointer constant in the presence of overloaded
    functions can lead to a *programming* bug. I'm not aware of any C++
    compiler that has a bug in this area (i.e., handles it in a way that's inconsistent with what the language requires).

    That kind of programming bug can be avoided by using nullptr rather than
    0 (something that wasn't possible before C++11).

    If you're suggesting changing the language so that 0 is no longer a null pointer constant, that would break tons of existing code.

    Yes. But if you want that effect, some compilers will give you it with
    the right flags (-Werror=zero-as-null-pointer-constant in gcc).

    The downside of backwards compatibility in C and C++ is that it is hard
    to remove features, even if they have been shown to be dangerous or
    replaced by significantly better alternatives. Look how long it has
    taken C to get rid of non-prototype function declarations - 33 years,
    assuming C23 comes out on plan.

    It would be nice if there were some way to standardise options like this
    in a cross-compiler fashion (perhaps with pragmas rather than compiler
    flags, so that they are included in the source code). The C++ and C
    committees [[attributes]] to standardise common extensions (gcc/clang __attribute__, MSVC declspec). So I live in hope!



    Programming bugs, compiler bugs, and language bugs are three very
    different things.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)