"Distinguishing between maybe-null vs never-null is the important thing"

[Lynn McGuire]

"Distinguishing between maybe-null vs never-null is the important thing"
https://herbsutter.com/2017/02/15/distinguishing-between-maybe-null-vs-never-null-is-the-important-thing/

This is above me.

The strength of C and C++ are null pointers. The weakness of C and C++ are null pointers.

Lynn

[Alf P. Steinbach]

On 15.02.2017 19:13, Lynn McGuire wrote:
> "Distinguishing between maybe-null vs never-null is the important thing"
>
> https://herbsutter.com/2017/02/15/distinguishing-between-maybe-null-vs-never-null-is-the-important-thing/
>
>
> This is above me.

No, it's just Herb writing it in a perhaps needlessly Difficult Way™.

Consider this short quote:

“people by convention use references for not-null parameters in
particular and so in modern C++ code the presence of a T*parameter often
(not always) implies nullability by that convention.”

I think that's it in a nutshell, for what Herb is focusing on here.

A reference like `T&` is the way to represent a non-null reference.

`T& o` is pretty specific: `o` is a single object of type `T`.

For a raw pointer `T* p` there are many possibilities even in valid code:

• `p` is null.
• `p` is non-null but doesn't point to an object (e.g., beyond an array).
• `p` is invalid, e.g. an indeterminate or dangling pointer.
• `p` points to an array (so, e.g., use `delete[]` for deletion, and in
particular don't upcast or downcast and use the result for indexing).
• `p` points to a single object of type `T`, like `o`.

I find it curious that Herb only focuses on the first point above, the
nullpointer possibility (at least in what I read of it), but maybe he
reasoned that was quite enough for a blog posting.

> The strength of C and C++ are null pointers. The weakness of C and C++
> are null pointers.

This is so also in Java, C#, Python, ... :)

In particular, for Java I recall problems with serialization for RPC of
structures that could contain null-references.

And then there's the database null versus empty string versus
nullpointer versus the literal `0` versus `{}` versus whatever.


Cheers!,

- Alf

[Rick C. Hodgin]

I address this in my (under development) CAlive language (an amalgam
of mostly C with the basic class added in) in something I call "i
blocks". The general rule is always test every pointer, unless you
have already tested it. In that case, convey it forward in the no-
test-needed state.

https://groups.google.com/d/msg/caliveprogramminglanguage/mqxBk0-lyqM/4VyM1dFeBQAJ

Externally exposed api functions have no "i" or "ii" prefix. Internal
functions are prefixed with an "i". And if it is known they will
receive only non-NULL parameters, then they are prefixed with an "ii".

However, to save declaration, I allow iiFunction() definitions which
then include an i {..} block, which allows iiFunction() to be called
as iiFunction() or iFunction(). When called as iiFunction(), it skips
the i {..} block. When called as iFunction() it traverses it.

bool iiFunction(someptr* p)
{
// Only test if called as iFunction()
i {
if (!p) {
raise_some_error();
do_whever_else();
return false;
}
}

// Normal code for both iFunction() and iiFunction() goes here
}

And, you can have multiple i {..} blocks within wherever they're
needed based on the condition of entering an ii() or i() function.

Thank you,
Rick C. Hodgin

[Öö Tiib]

On Wednesday, 15 February 2017 21:06:06 UTC+2, Alf P. Steinbach wrote:
>
> A reference like `T&` is the way to represent a non-null reference.
>
> `T& o` is pretty specific: `o` is a single object of type `T`.

The 'o' can also be dangling reference to object whose life-time has
already ended in well-formed code.

> For a raw pointer `T* p` there are many possibilities even in valid code:
>
> • `p` is null.
> • `p` is non-null but doesn't point to an object (e.g., beyond an array).
> • `p` is invalid, e.g. an indeterminate or dangling pointer.
> • `p` points to an array (so, e.g., use `delete[]` for deletion, and in
> particular don't upcast or downcast and use the result for indexing).
> • `p` points to a single object of type `T`, like `o`.

Might be worth to note that with array 'p' can point at first element
of array, any other elements of array and one past end of array.

[Manfred]

As far as I am concerned, this looks to me of no (or negligible) use:

Explicit pointers are one of the greatest capabilities of C++ (inherited
from C). Obviously one needs to know how to use them (so what?), and C++
has better alternatives (iterators etc.) for a number of cases. But they
are nonetheless pretty valuable as I see them.

About nullable pointers, to me it is that simple:
- if you need it to be guaranteed to refer to an actual object, use a T&
- if you need to allow for no-object referred, use a T*

It is clear, compact and type safe. What more?

[Tim Rentsch]

Manfred <non...@invalid.add> writes:

> About nullable pointers, to me it is that simple:
> - if you need it to be guaranteed to refer to an actual object,
> use a T&
> - if you need to allow for no-object referred, use a T*
>
> It is clear, compact and type safe. What more?

What if you want a variable that is guaranteed to refer to an
actual object, but now and then you want to change which object
it refers to?

[Alf P. Steinbach]

That's std::reference_wrapper<T> for you.

Copy assignment of a `std::reference_wrapper` makes it refer to another
object.


Cheers!,

- Alf

[Manfred]

Alf already answered about std::reference_wrapper, but I may add that
IME if you have a well defined problem domain, when a variable needs to
refer to selectable objects, most often it requires to be allowed to
refer to no object as well: typically such a variable is meant to
address an object in a set, and typically sets can be empty.

[Tim Rentsch]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:

> On 17.02.2017 16:08, Tim Rentsch wrote:
>> Manfred <non...@invalid.add> writes:
>>
>>> About nullable pointers, to me it is that simple:
>>> - if you need it to be guaranteed to refer to an actual object,
>>> use a T&
>>> - if you need to allow for no-object referred, use a T*
>>>
>>> It is clear, compact and type safe. What more?
>>
>> What if you want a variable that is guaranteed to refer to an
>> actual object, but now and then you want to change which object
>> it refers to?
>
> That's std::reference_wrapper<T> for you.

I didn't know about reference_wrapper. Interesting.

> Copy assignment of a `std::reference_wrapper` makes it refer to
> another object.

I played around with reference_wrapper a bit, and it strikes me
as, well, maybe I would say a bit off. Or clunky? I appreciate
the semantics, clearly it would be useful in some circumstances,
but the interface is rather (if I may use a technical term) icky.

[Tim Rentsch]

No doubt that property is often true, but certainly it isn't
always true. A couple of counterexamples immediately come to
mind: one, a circular list (doubly linked) with a dummy node
pointing to the head and tail; and two, a 2-3 tree with internal
nodes (holding 1 value and 2 subtrees, or 2 values and 3
subtrees) and leaf nodes (holding 1 value or 2 values, and no
subtrees). Any external pointers to these structures are most
likely nullable, but the internal pointers should never be null
(and they do need to change as the structures grow and shrink).

It would be interesting to try a language experiment where
pointer types normally are not nullable, and a pointer type that
needs to be nullable would require writing, eg,

int *nullable p;

(I may have read this suggestion somewhere else, and if I could
remember if and where I would gladly give credit. I make no
claim for originality here.)

[Manfred]

On 2/18/2017 5:36 PM, Tim Rentsch wrote:
> No doubt that property is often true, but certainly it isn't
> always true.

Agreed.
My point was about common use, specific cases are always possible.
The question is if the language should provide explicit facilities for
such specific cases.
Personally I think that added features always carry some cost, so they
should be widely applicable to be justified.
I always liked the essential nature of C++ - I mean being based on a
limited number of powerful and solid concepts - as opposed to other
languages that are more feature-richness oriented, but quite dispersed
into a plethora of specific use cases.

[Tim Rentsch]

Manfred <non...@invalid.add> writes:

> On 2/18/2017 5:36 PM, Tim Rentsch wrote:
>> No doubt that property is often true, but certainly it isn't
>> always true.
>
> Agreed.
> My point was about common use, specific cases are always possible.
> The question is if the language should provide explicit facilities for
> such specific cases.
> Personally I think that added features always carry some cost, so they
> should be widely applicable to be justified.

Yes, we are very much on the same page on the last point.

For the particular case in point though I think it would have
been easy (or maybe should have been easy?) to fold an updatable
reference (or non-nullable pointer) into the language for very
little cost (meaning of course very little incremental cost). Of
course, that still leaves the question of whether the benefits
(whatever those may be) justify that cost.

> I always liked the essential nature of C++ - I mean being based on a
> limited number of powerful and solid concepts - as opposed to other
> languages that are more feature-richness oriented, but quite dispersed
> into a plethora of specific use cases.

I quite agree with you on the philosophy. But my impression of
C++ is more towards the other end of the spectrum than what you
describe. Please don't take that as an argument, I mean only to
note a difference in perception.

[Manfred]

On 2/19/2017 4:40 PM, Tim Rentsch wrote:
>> I always liked the essential nature of C++ - I mean being based on a
>> limited number of powerful and solid concepts - as opposed to other
>> languages that are more feature-richness oriented, but quite dispersed
>> into a plethora of specific use cases.
> I quite agree with you on the philosophy. But my impression of
> C++ is more towards the other end of the spectrum than what you
> describe. Please don't take that as an argument, I mean only to
> note a difference in perception.

What I had in mind was in fact C++ as originally designed, and up to and
including C++11.
For what I can see about the latest variants C++14 and C++17 I may
indeed share your perception.

[woodb...@gmail.com]

My hope is string_view would be back-ported to C++ 2011 compilers.
Also it would help to have support for "parameter type deduction
for constructors" or at least make_unique in C++ 2011 compilers.
I could live though, without that, but need the support for string_view.


Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[Chris Vine]

On Mon, 20 Feb 2017 10:12:13 -0800 (PST)
woodb...@gmail.com wrote:
[snip]

> My hope is string_view would be back-ported to C++ 2011 compilers.
> Also it would help to have support for "parameter type deduction
> for constructors" or at least make_unique in C++ 2011 compilers.
> I could live though, without that, but need the support for
> string_view.

What a weird suggestion. Why would anyone want to "backport" C++14/17
to C++11? It would no longer be C++11.

A more reasonable suggestion is that compilers should be incrementally
updated to C++14/C++17. Such a suggestion would be otiose: that is
already happening. It appears you may have failed to adopt the correct
compiler flags. gcc, clang and visual studio have supported
make_unique for some time (-std=c++14 for gcc/clang). Recent versions
of libstdc++ and libc++ also (as I understand it) support string_view
although I have never used it. No doubt VS will follow in the
relatively near future.

[woodb...@gmail.com]

On Monday, February 20, 2017 at 12:59:13 PM UTC-6, Chris Vine wrote:
> On Mon, 20 Feb 2017 10:12:13 -0800 (PST)
> woodb...@gmail.com wrote:
> [snip]
> > My hope is string_view would be back-ported to C++ 2011 compilers.
> > Also it would help to have support for "parameter type deduction
> > for constructors" or at least make_unique in C++ 2011 compilers.
> > I could live though, without that, but need the support for
> > string_view.
>
> What a weird suggestion. Why would anyone want to "backport" C++14/17
> to C++11? It would no longer be C++11.

C++ 2011 was both late and incomplete. There's no reason
string_view couldn't have been part of C++ 2011 and, in an
ideal world, it would have been.

>
> A more reasonable suggestion is that compilers should be incrementally
> updated to C++14/C++17.

As someone mentioned upthread, a lot of C++ 2014 and 2017 isn't
needed. Compiler vendors could make their C++ 2011 compilers
better by taking this step.

> Such a suggestion would be otiose: that is
> already happening. It appears you may have failed to adopt the correct
> compiler flags. gcc, clang and visual studio have supported
> make_unique for some time (-std=c++14 for gcc/clang). Recent versions

I use those flags, but would rather not require users to
have a C++ 2014 or 2017 compiler. Probably there are (or
will be) others with the same request.


Brian
Ebenezer Enterprises - Because children deserve to have
a father and a mother.

http://webEbenezer.net

[Chris Vine]

Brian,

This is meaningless and bizarre. If you want C++14 or C++17 features
you use the appropriate compiler flag. Whether or not C++11 was
incomplete is beside the point, as is whether or not C++11 should have
had a string_view. It didn't. C++17 does. So you use the C++17
compiler flag if you want it. Move on.

I am kind of left scratching my head over your lack of reasonable
logic. I think the religious mania of you and your nutjob colleague is
affecting your judgement.

[woodb...@gmail.com]

It doesn't hurt to ask, though, does it?


Brian
Ebenezer Enterprises - "Love your enemies and pray for those who
persecute you that you may be children of your Father in heaven.
He causes the sun to rise on the evil and the good, and sends rain
on the righteous and the unrighteous." Matthew 5:44,45

http://webEbenezer.net

[Chris Vine]

On Mon, 20 Feb 2017 14:38:55 -0800 (PST)
woodb...@gmail.com wrote:
[snip]

> It doesn't hurt to ask, though, does it?

Yes, asking for something ridiculous and illogical does hurt. It hurts
those who have to spend some of their valuable cognitive capacity asking
themselves whether you are for real or just out there somewhere in
space; and it hurts you because you wouldn't be taken seriously in the
future.

And it hurts my religion by having someone who proselytizes for some
bizarre out-stream of it showing themselves to be so lacking in any
actual reasoning capacity.

[woodb...@gmail.com]

By attacking my reasoning you are attempting to dissuade people
from looking into my work. Same old same old from you for years,
Chris. If you can't offer some constructive criticism, I suggest
you say nothing.

[woodb...@gmail.com]

On Monday, February 20, 2017 at 12:59:13 PM UTC-6, Chris Vine wrote:
> On Mon, 20 Feb 2017 10:12:13 -0800 (PST)
> woodb...@gmail.com wrote:
> [snip]
> > My hope is string_view would be back-ported to C++ 2011 compilers.
> > Also it would help to have support for "parameter type deduction
> > for constructors" or at least make_unique in C++ 2011 compilers.
> > I could live though, without that, but need the support for
> > string_view.
>
> What a weird suggestion. Why would anyone want to "backport" C++14/17

I didn't come up with the idea of backporting:

https://en.wikipedia.org/wiki/Backporting

I don't suggest backporting all of the features, just one or two.


Brian
Ebenezer Enterprises
http://webEbenezer.net

[Chris Vine]

On Mon, 20 Feb 2017 15:03:03 -0800 (PST)
woodb...@gmail.com wrote:
[snip]

> By attacking my reasoning you are attempting to dissuade people
> from looking into my work. Same old same old from you for years,
> Chris. If you can't offer some constructive criticism, I suggest
> you say nothing.

That is outrageous. I have never even looked at your work (if by that
you mean your serializing product), let alone attacked it. Please
correct me by showing some post (any post) of mine which has referred to
it, or apologize if you are man enough to do so: I suspect you are not.

Your posts on this topic of "backporting" C++14/17 features to a C++11
compiler are ridiculous. But that is a separate matter.

I have now become cross with you.

[Öö Tiib]

C++ specification is not made like those softwares with versions
1.14.3 and 2.3.7 in parallel maintenance and extension AFAIK.

There was C++ 2011 standardized and there won't be 2011.0.1 bugfix
release nor 2011.1 extended feature releases of it. It is done.
Defects of 2011 were attempted to address in version 2014. That is
also final. Version 2017 is under development.

[Robert Wessel]

On Fri, 24 Feb 2017 12:50:21 -0800 (PST), 嘱 Tiib <oot...@hot.ee>
wrote:

Well, they do accept defect reports, and then issue corrections or
whatever to the standard as is appropriate. Here are some of the ones
for the C++11 core language:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html