Hi group.

There are no construct of an pointer, which can change its value, but
may not be 0 (if I remember correctly).

Plain pointer can change its value but may be 0.
References cannot change its value and may not be 0.
Constant pointers cannot change its value but may be 0.

In other words:

        |   constant   |  non-constant
--------+--------------+-----------------
maybe 0 |  foo* const  |      foo*
--------+--------------+-----------------
never 0 |     foo&     |      ???


Are there a reason why there is not the fourth type?

Let's say, that there is a special modifier called __nonnull. (Maybe
there are compilers out already support this?)

I found a small reason: You cannot completly check the assignment to 0
at compile time, so if there would be such a construct, you have to
live with some "undefined behaviour" - thingie when trying to assign 0
to that value (as it is currently with the 0-reference). And you can
take the normal foo* for this case (and claim that assigning 0 to the
pointer is your definition of UB).

But compilers could detect and error *some* illegal accesses.
Oh, and it would be great as an documenting feature, instead of a
comment "This is never 0".

__nonnull foo* p = new foo;
__nonnull foo* p2 = p;
.
p = 0;  // compile time error possible
.
p = p2; // unfortunatly no compile time error possible


What do you say? Had someone already written a proposal on that? Is it
too unimportant to be noticed? ;)


Ciao, Immanuel Scholz.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

einwegadresse@gmx.de wrote:
> Hi group.
>
> There are no construct of an pointer, which can change its value, but
> may not be 0 (if I remember correctly).
>
> Plain pointer can change its value but may be 0.
> References cannot change its value and may not be 0.
> Constant pointers cannot change its value but may be 0.

References are NOT pointers.

>
> Are there a reason why there is not the fourth type?

Because there isn't even the third type.
The only reason references can't be zero, is they can't be rebound.

>
> Let's say, that there is a special modifier called __nonnull. (Maybe
> there are compilers out already support this?)

Not really useful.  Just because a pointer value isn't null, doesn't
mean it's valid.

References connect to objects, so you know that (at least at the time
of their creation).  Pointers never have that guarantee, the language
doesn't even enforce default initialization on them.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi again,

Ron Natalie schrieb:
> einwegadresse@gmx.de wrote:
> > There are no construct of an pointer, which can change its value, but
> > may not be 0 (if I remember correctly).
> >
> > Plain pointer can change its value but may be 0.
> > References cannot change its value and may not be 0.
> > Constant pointers cannot change its value but may be 0.
>
> References are NOT pointers.

I did not say that. However, I said, that references are (c++ language)
constructs.
And I said, that references cannot be 0 and cannot change its value
(means "rebound").


> > Are there a reason why there is not the fourth type?
>
> Because there isn't even the third type.
> The only reason references can't be zero, is they can't be rebound.

So why references aren't the third type of language construct? They can
not be 0 and can not change its value. The reason *why* they can not be
0 is not of interest, as long as they CANNOT be 0.


> > Let's say, that there is a special modifier called __nonnull. (Maybe
> > there are compilers out already support this?)
>
> Not really useful.  Just because a pointer value isn't null, doesn't
> mean it's valid.

That applies to the reference as well. I mean, references are never
null, but this does not mean, they are always valid.

To be honest, I did not thought fully about the usability of the fourth
construction (a pointer which may not be 0). Maybe there are just too
few cases where the compiler really can report an error for such thing,
so it's use it too limited.

One use could clearly as a documentation, but you can achieve this
with:

#define __nonnull

as well and then write

__nonnull foo* bar;

(I know, "__nonnull" is not a good name for this)


> References connect to objects, so you know that (at least at the time
> of their creation).  Pointers never have that guarantee, the language
> doesn't even enforce default initialization on them.

References may be invalid as well as pointers may be invalid (as
example in if you hold a reference to a valid pointer and then delete
that pointer).

And about default initialisation: If you access an uninitialized
reference, you get "the same" undefined behaviour as if you access an
uninitialized pointer.


(It is much harder to access an uninitialized reference. Maybe that
should do the trick:)

class foo
{
  int i,j;
  int& b;
  foo() : i(b), b(j) {}
}


I don't want to upset someone with wrong vocabulary, as I don't know
the standard as well as you all. If "pointer" or "reference" has some
additional meaning beside beeing "a c++ language construct that can
hold a connection to an object" then in my posting I would like to
restricts the point of interest to this definition.

If there is another construct that can simulate an connection to an
object, can change its value (means: connect to another object) but can
not be 0, I am most interested how to use this. If not, I'd like to ask
whether there could be fundamental problems with such a construct.

Ciao,
Immanuel Scholz.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]