[QT creator free, on "nix"], about NULL, nullptr etc

[Soviet_Mario]

I still sometimes write C-like casts like

if (MyPointer == (classPincoPallo *)(0)) {}

then QT ide slams me for "old styled" fashion, so I rewrite

if (MyPointer == static_cast <classPincoPallo *> (0)) {}

and it again complaints until i correct further to

if (MyPointer == static_cast <classPincoPallo *> (nullptr)) {}

now, WHAT exactly is the nullptr ? Is it really different
from ZERO (all-zeroes-bit pattern of the word size) ?

If it is a zero, why the ide complaints as it was just
casted in a zero of a proper type ?

if it is not zero, is it some "system-dependent" numeric
constant ?
Why should it better than zero ?
Is it a bigger than bigger ram address value ?

I'm confused about the pointer "nullity" management.

Long ago casting a 0 had been enough :\



--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[Bo Persson]

On 2019-11-19 at 20:49, Soviet_Mario wrote:
> I still sometimes write C-like casts like
>
> if (MyPointer == (classPincoPallo *)(0)) {}
>
> then QT ide slams me for "old styled" fashion, so I rewrite
>
> if (MyPointer == static_cast <classPincoPallo *> (0)) {}
>
> and it again complaints until i correct further to
>
> if (MyPointer == static_cast <classPincoPallo *> (nullptr)) {}
>
> now, WHAT exactly is the nullptr ? Is it really different from ZERO
> (all-zeroes-bit pattern of the word size) ?
>
> If it is a zero, why the ide complaints as it was just casted in a zero
> of a proper type ?
>
> if it is not zero, is it some "system-dependent" numeric constant ?
> Why should it better than zero ?
> Is it a bigger than bigger ram address value ?
>
> I'm confused about the pointer "nullity" management.
>
> Long ago casting a 0 had been enough :\
>

The nullptr is just a literal for a null pointer, of any pointer type.
Absolutely no reason to cast it to anything - it already is of that
pointer type (and all others as well).

Also, to be predantic, the null pointer doesn't have to be all-zero-bits
if the system prefers some other representation (all 1-bits have been
seen on systems without an MMU, where actually writing to address 0
could break the OS :-).

In any case, both 0 and nullptr will represent the proper value,
whatever it is.



Bo Persson

[Alf P. Steinbach]

On 19.11.2019 20:49, Soviet_Mario wrote:
> I still sometimes write C-like casts like
>
> if (MyPointer == (classPincoPallo *)(0)) {}
>
> then QT ide slams me for "old styled" fashion, so I rewrite
>
> if (MyPointer == static_cast <classPincoPallo *> (0)) {}
>
> and it again complaints until i correct further to
>
> if (MyPointer == static_cast <classPincoPallo *> (nullptr)) {}
>
> now, WHAT exactly is the nullptr ? Is it really different from ZERO
> (all-zeroes-bit pattern of the word size) ?
>
> If it is a zero, why the ide complaints as it was just casted in a zero
> of a proper type ?
>
> if it is not zero, is it some "system-dependent" numeric constant ?
> Why should it better than zero ?
> Is it a bigger than bigger ram address value ?
>
> I'm confused about the pointer "nullity" management.
>
> Long ago casting a 0 had been enough :\

It's just the IDE bullying you.

`nullptr` is more safe than `0`, because the latter can be interpreted
as integer zero. However, `0` can be more readable.

It's not a choice that the IDE can reasonably make, so check if you can
configure it away?

The `nullptr` notation originated with Scott Meyers, who defined a
nullptr_t class in the C++03 days. And so, following that design,
`nullptr` in itself designates a value, of type `nullptr_t`, that is
/convertible/ to any T* nullpointer. One nice feature of that scheme is
that one can use `nullptr_t` as a function parameter type.

A nullpointer of a given type T* is a nullpointer regardless of
notation, and it's not guaranteed to be the bitpattern all zeroes even
when it's designated by `0`.

- Alf

[Paavo Helde]

On 19.11.2019 21:49, Soviet_Mario wrote:
> I still sometimes write C-like casts like
>
> if (MyPointer == (classPincoPallo *)(0)) {}

This should read:

if (!MyPointer) { /*...*/ }

or if you insist:

if (MyPointer == nullptr) { /*...*/ }

There is no point in adding extra noise to your code.

[Öö Tiib]

On Tuesday, 19 November 2019 21:49:57 UTC+2, Soviet_Mario wrote:
> I still sometimes write C-like casts like
>
> if (MyPointer == (classPincoPallo *)(0)) {}
>
> then QT ide slams me for "old styled" fashion, so I rewrite
>
> if (MyPointer == static_cast <classPincoPallo *> (0)) {}
>
> and it again complaints until i correct further to
>
> if (MyPointer == static_cast <classPincoPallo *> (nullptr)) {}

You clearly over-engineered there.

Installed also qt-creator to see what Clang-Tidy and Clazy in it say
by default and how to change it.

By default it seems that:

if (MyPointer == 0) // gives warning: zero as null pointer constant

if (!MyPointer) // no warnings

if (MyPointer == nullptr) // no warnings

I actually like last two better so I would not touch it but lets see if it
is possible to change so all 3 to give no warnings.

Seems that disabling the warning .pro file like ...

QMAKE_CXXFLAGS += "-Wno-zero-as-null-pointer-constant"

... removes it also in editor.

[Soviet_Mario]

Il 19/11/19 20:49, Soviet_Mario ha scritto:

> I still sometimes write C-like casts like
>
> if (MyPointer == (classPincoPallo *)(0)) {}
>
> then QT ide slams me for "old styled" fashion, so I rewrite
>
> if (MyPointer == static_cast <classPincoPallo *> (0)) {}
>
> and it again complaints until i correct further to
>
> if (MyPointer == static_cast <classPincoPallo *> (nullptr)) {}
>
> now, WHAT exactly is the nullptr ? Is it really different
> from ZERO (all-zeroes-bit pattern of the word size) ?
>
> If it is a zero, why the ide complaints as it was just
> casted in a zero of a proper type ?
>
> if it is not zero, is it some "system-dependent" numeric
> constant ?
> Why should it better than zero ?
> Is it a bigger than bigger ram address value ?
>
> I'm confused about the pointer "nullity" management.
>
> Long ago casting a 0 had been enough :\
>
>
>

tnx to you all for advices.
I'll avoid the extra unessential cast (I hadn't thought of
trying to remove it)

[Scott Lurndal]

Soviet_Mario <Sovie...@CCCP.MIR> writes:

>now, WHAT exactly is the nullptr ? Is it really different
>from ZERO (all-zeroes-bit pattern of the word size) ?

A NULL pointer need not have the value zero; I recall an
architecture where NULL pointers were indicated by the
sentinal value EEEEEE (yes, 6 4-bit digits).

[James Kuyper]

NULL is a C++ standard macro. "null" is an adjective that applies in
several C++ contexts, one of the most important being the phrase "null
pointer". C++ is a case sensitive language, so I don't think it counts
as pedantry to point out that these are different things.

Before nullptr was invented, NULL was not only allowed, but required to
expand into a null pointer constant: an integer literal with a value of
0. What you're actually talking about is a null pointer. The value of a
pointer is the location where it points at. What you're talking about is
not the value of the pointer, but it's representation. There is indeed
no requirement that a null pointer have all bits 0, and there are real-
world implementations where this is not the case.

Note also that even if "E" is an expression with an integer type and a
value of 0, (T*)E is not guaranteed to produce a null pointer value
That guarantee requires an integer literal.

[Scott Lurndal]

I'm sorry to have inadvertantly confused you. The Architecture is question
used the 24-bit value 0xeeeeee as the sentinal value that indicated
end of a linked list of entries. That is one purpose of C's null/NULL
pointer. And of course languages other than C also have a concept of
a NULL pointer by whatever name you want to use.

The machine was a BCD machine without fixed operand sizes[*] (pointers
were originally six BCD digits because the machine only supported
one million digits (500kB) of memory). Later, a multi-level segmenting
scheme was added to the architecture which exended pointers to 8 BCD
digits (co-incidentally 32-bits). The high order 8 bits of the pointer
were a sign digit and a base selector digit; the remaining 6 digits
were the offset from the specified base register. Those 6 digits were
set to the value 0xEEEEEE (an invalid BCD address) to indicate end
of list (and for a null pointer); The hardware had instructions to walk
linked lists (SLT instruction) and the hardware reinstate list (the list
of read-to-run thread/task/process contexts) was also organized as a linked
list and was dispatched using the privileged BRV (Branch Reinstate Virtual) instruction.

[*] The arithmetic instruction operands could be from one to 100 digits
(or bytes with the zone digit ignored) in length.

While we tried a couple times to make a useful C compiler for the architecture,
the lack of any form of bit shifting and/or rotation instructions made it
too inefficient for the architecture, which frankly was designed specifically
for COBOL.

[James Kuyper]

On Thursday, November 21, 2019 at 10:44:42 AM UTC-5, Scott Lurndal wrote:
> James Kuyper <james...@alumni.caltech.edu> writes:
...

> >NULL is a C++ standard macro. "null" is an adjective that applies in
> >several C++ contexts, one of the most important being the phrase "null
> >pointer". C++ is a case sensitive language, so I don't think it counts
> >as pedantry to point out that these are different things.

...

> I'm sorry to have inadvertantly confused you.

No problem - you didn't confuse me. I immediately realized that you were
incorrectly using "NULL pointer" where you should have said "null
pointer". I was merely trying to get you to correct your usage, since,
sooner or later, you're likely to misuse those terms in a context where
it will cause confusion.
I was apparently unsuccessful, since you went on to use NULL incorrectly
two more times: