NULL versus 0

[das...@gmail.com]

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.

[Branimir Maksimovic]

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

> Thanks.
>


--

7-77-777
Evil Sinner!

[Paavo Helde]

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;

[Paavo Helde]

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.

[das...@gmail.com]

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

[see.my....@gmail.com]

> 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

[James Kuyper]

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.

[Jorgen Grahn]

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 .

[Branimir Maksimovic]

On 2021-09-26, Jorgen Grahn <grahn...@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!

[Keith Thompson]

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.T...@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[Keith Thompson]

Jorgen Grahn <grahn...@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.

[Branimir Maksimovic]

On 2021-09-26, Keith Thompson <Keith.S.T...@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!

[Bo Persson]

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

[Horsey...@the_stables.com]

On 26 Sep 2021 06:58:15 GMT

Jorgen Grahn <grahn...@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.

[Keith Thompson]

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

[Juha Nieminen]

Paavo Helde <myfir...@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.)

[Chris M. Thomasson]

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?

;^)

[Bo Persson]

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.

[Chris M. Thomasson]

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

;^)

[Alf P. Steinbach]

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

[Keith Thompson]

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.

[James Kuyper]

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)

[Branimir Maksimovic]

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!

[Branimir Maksimovic]

On 2021-09-26, Keith Thompson <Keith.S.T...@gmail.com> wrote:
> Branimir Maksimovic <branimir....@gmail.com> writes:
>> On 2021-09-26, Keith Thompson <Keith.S.T...@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!

[Keith Thompson]

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.

[David Brown]

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!