Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #81582 > unrolled thread

NULL versus 0

Back to article view | Back to comp.lang.c++

Contents

  NULL versus 0 "das...@gmail.com" <dashley@gmail.com> - 2021-09-25 11:03 -0700
    Re: NULL versus 0 Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 18:16 +0000
    Re: NULL versus 0 Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-25 21:20 +0300
      Re: NULL versus 0 Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-25 21:32 +0300
        Re: NULL versus 0 "das...@gmail.com" <dashley@gmail.com> - 2021-09-25 12:08 -0700
      Re: NULL versus 0 Juha Nieminen <nospam@thanks.invalid> - 2021-09-27 05:47 +0000
        Re: NULL versus 0 Bo Persson <bo@bo-persson.se> - 2021-09-27 08:32 +0200
          Re: NULL versus 0 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-26 23:37 -0700
          Re: NULL versus 0 "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-27 10:32 +0200
            Re: NULL versus 0 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-27 11:32 -0700
        Re: NULL versus 0 James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-27 15:03 -0400
    Re: NULL versus 0 "see.my....@gmail.com" <see.my.homepage@gmail.com> - 2021-09-25 13:05 -0700
      Re: NULL versus 0 Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-09-26 06:58 +0000
        Re: NULL versus 0 Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-26 07:47 +0000
          Re: NULL versus 0 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-26 02:15 -0700
            Re: NULL versus 0 Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-26 09:38 +0000
              Re: NULL versus 0 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-26 15:03 -0700
                Re: NULL versus 0 Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-29 02:29 +0000
                  Re: NULL versus 0 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-28 20:34 -0700
                    Re: NULL versus 0 David Brown <david.brown@hesbynett.no> - 2021-09-29 08:52 +0200
          Re: NULL versus 0 Bo Persson <bo@bo-persson.se> - 2021-09-26 13:54 +0200
            Re: NULL versus 0 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-26 15:17 -0700
            Re: NULL versus 0 Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-29 02:26 +0000
        Re: NULL versus 0 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-26 02:17 -0700
        Re: NULL versus 0 HorseyWorsey@the_stables.com - 2021-09-26 14:20 +0000
    Re: NULL versus 0 James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-25 17:36 -0400
    Re: NULL versus 0 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-26 23:05 -0700

Page 1 of 2  [1] 2  Next page →

#81582 — NULL versus 0

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.

[toc] | [next] | [standalone]

#81583

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!

[toc] | [prev] | [next] | [standalone]

#81584

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;

[toc] | [prev] | [next] | [standalone]

#81585

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.

[toc] | [prev] | [next] | [standalone]

#81586

> 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!

[toc] | [prev] | [next] | [standalone]

#81612

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.)

[toc] | [prev] | [next] | [standalone]

#81614

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.

[toc] | [prev] | [next] | [standalone]

#81615

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=e320776c84d666caf19b80ac7925f3d9e30ab3d99e0ab58d634535629abb3d2f4b8a981dc0fbd9024aca3d2a2b29de38323340cf7e700b8599ddfac7d6d5972d0a2e8b8e9d751ecf0ea7a25e9394a86496ab208cb5b846f01bdff721feb48f8ece892344689b3d8db8bb39c3b21dfe4aad2f65608c0ef1ca3737a23b63c09ba2b0dad9ccd9a81cbf3a53a480bc0a55f9be590f6e021c787972bddce2f249e45137f75884f82bc74fa8115f0339b4c1515b55dfefd1f8322f16de06c50b5e3b7381f4d044ad9cdfad661d9c677e63a5c440ef9ac49c3a78c5397fe4ee2039d79cc7d790fe11036f99b6a3e9b8a6c738a84deccdf24d1277cbc081ae42398979a04346e34e6f3a135cdf6a3cf78b771a7bf052564c27e6767ad769141be938f1c35dff31c353311989339523a3dad8a8530e2301303329aa050ce085a6135338f3bdcef27485f2843df96ce01cee17b17ef5db63b621392c7dc08487add5c382d40199a67b6978f83650e3c586d67207731ed42b954b433ef6ff8f84b06456b9394eb610b116cfefe266a185


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;
}
_____________________________

;^)

[toc] | [prev] | [next] | [standalone]

#81619

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

[toc] | [prev] | [next] | [standalone]

#81626

"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 */

[toc] | [prev] | [next] | [standalone]

#81627

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)

[toc] | [prev] | [next] | [standalone]

#81587

> 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

[toc] | [prev] | [next] | [standalone]

#81596

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   .

[toc] | [prev] | [next] | [standalone]

#81597

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!

[toc] | [prev] | [next] | [standalone]

#81598

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 */

[toc] | [prev] | [next] | [standalone]

#81600

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!

[toc] | [prev] | [next] | [standalone]

#81605

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 */

[toc] | [prev] | [next] | [standalone]

#81661

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!

[toc] | [prev] | [next] | [standalone]

#81666

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 */

[toc] | [prev] | [next] | [standalone]

#81668

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.
> 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web