Topic: Why's of C++ -- Part 1 (NULL)


Author: sbnaran@uiuc.edu (Siemel B. Naran)
Date: 1999/08/16
Raw View
On 14 Aug 99 08:27:17 GMT, David R Tribble <david@tribble.com> wrote:
>"Siemel B. Naran" wrote:
>> Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:

>>> Now, please answer this question: what is the type of NULL ?
>> In the ideal language, NULL would be deprecated.

>No, an ideal language would have a true 'null' keyword and the
>practice of using integer constants as null pointers would be
>deprecated.

Yes, the practice of using integer constants as null pointers
would be deprecated.  Hence,
   int * ptr=0; // error: cannot convert int to int*

And the NULL macro which is a SHORT-hand for "0" or "(void*)0"
simply wouldn't exist.
   int * ptr1=null; // ok: 'null' has type int*
   double * ptr2=null; // ok: 'null' has type double*
   int val1=null; // error: type of 'null' unknown
   (void) null; // error: type of 'null' unknown

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: "Greg Brewer" <nospam.gregb@hal-pc.org>
Date: 1999/08/16
Raw View
blargg <postmast.root.admi.gov@iname.com> wrote in message
news:user-1308991418170001@as1-dialup-03.io.com...
> In article <7ov8et$1s0q$1@news.hal-pc.org>, "Greg Brewer"
> <nospam.gregb@hal-pc.org> wrote:
>
> > Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote in message
> > news:37B2E2E2.3CA3@wanadoo.fr...
> > > You are the 34324th person who proposes that.
> > >
> > > Now, please answer this question: what is the type of NULL ?
> >
> > Only 34234th, I would have thought is more like 34688th.  ;-)
> >
> > Seriously, NULL would remain a macro.  The value the NULL resolves to
would
> > be of type universal pointer.  It would be unique in that it would be
the
> > only literal value capable of having that type.
> >
> >    typeof(NULL) x = &anything;   // would be illegal.
> >
> >   if (typeof(NULL) == typeof(anything) )   // is always false.
>
> What is typeof? Last time I checked, the language didn't allow comparison
> of types (the closest it allows is comparison of type_info objects, gotten
> with typeid).

That was pseudo code to demonstrate.  Nothing more.

> Why not make it special in that it has no type, and is not an object?

works for me!

> > The universal pointer can convert to any type of pointer.  No pointer
can
> > convert to a universal pointer.
>
> This sounds like the opposite of void*. Strange.

Exactly!

> > I just had an idea.  I once thought you might designate the null pointer
> > with a reserved word like unull; but, I think the literal value &0 would
be
> > better.  It something that currently gives me an error and involves
adding
> > no new reserved words that someone may already be using as a variable.
> >    #define NULL &0
> >
> > Come on troops.  Viva &0!
>
> So common. Sugar-coat the proposal at the end saying that "no code using
> this would be valid, so we could use this weird syntactic construct to
> represent this concept".
>
> Why would &0 be better? It would be a loosening of type-safety. Sure, we
> could make any ill-formed program have some valid interpretation for a new
> feature. Let's make trying to assign type X to type Y mean something new
> if type X can't normally be assigned to type Y.

Better than what?  Better than adding a new keyword?  Don't we have enought
reserved words?  It something I think would be unlikely to break existing
code that uses NULL keyword for the null pointer.  Making ((void *)0) a
special case of void * works for me just as well and works a lot better for
everyone than making 0 a special case of integer that can also be a pointer.

Greg Brewer



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1999/08/16
Raw View
In article <user-1308991418170001@as1-dialup-03.io.com>, blargg
<postmast.root.admi.gov@iname.com> writes
>Why would &0 be better? It would be a loosening of type-safety. Sure, we
>could make any ill-formed program have some valid interpretation for a new
>feature. Let's make trying to assign type X to type Y mean something new
>if type X can't normally be assigned to type Y.

Well actually we already do that with:

mytype mt_ptr = 0;

as an int cannot normally be assigned to a pointer.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1999/08/17
Raw View
blargg wrote:

[...]

> > The universal pointer can convert to any type of pointer.  No pointer can
> > convert to a universal pointer.
>
> This sounds like the opposite of void*. Strange.

Not really strange, and even seen in other strongly typed languages
as general type. I've already suggested a type "any*" earlier,
which would be exactly this.
Indeed, an appropriately defined "any" type would solve
several issues at once:

- Getting static or automatic memory aligned for any type:

  union
  {
    any alignment;
    char buffer[1000];
  }

  Now buffer has correct alignment for any type (since alignment
  and buffer are at the same address, and alignment is guaranteed
  to be correctly aligned for any type)

- Getting the numerical value of the maximum alignment of
  the implementation: sizeof(any)

- Improving C compatibility, by letting allocation functions
  return any*, like "any* malloc(size_t);". The following would
  then compile both with C and C++:

  int* a = malloc(sizeof(int));

- Allow definition of an universal null pointer constant: (any*)0

And all this _without_ breaking type safety, since there is no
automatic conversion _to_ any*, and any itself is a "singular"
type anyway, in that it would be a POD with no defined operations
besides the "standard" ones (default construct, copy construct,
assign and destruct).

[...]
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: James.Kanze@dresdner-bank.com
Date: 1999/08/17
Raw View
In article <7ouq67$noe$1@engnews1.eng.sun.com>,
  clamage@eng.sun.com (Steve Clamage) wrote:
> Valentin Bonnard <Bonnard.V@wanadoo.fr> writes:

> >> This universal null would be an untyped pointer that could be
> >> promoted to any type of pointer and 0 could only be an integer.

> >Now, please answer this question: what is the type of NULL ?

> It's the same type as "new" in a new-expression. :-)

The expression " new " is not legal in the language, so it doesn't need
a type.  (I cannot call a template function with f( new ), for example.)
The expression " NULL " is.  Of course, you could say it is the same
type as "this".  But even there, the expression "this" is only legal in
a specific context, where its type is fully determined.  Whereas what
would be the type of "NULL" in the following case:

    template< class T > void f( T arg ) ;

    void
    g()
    {
        f( NULL ) ;
    }

> That is, if you create a language keyword to represent a universal
> null pointer, its type would be determined from context. You could
> use it the same way in pointer contexts as 0 is used now, except
> there would be no ambiguity with an integer 0.

In the above example, integer 0 instantiates and calls f( int ).

This is a definite complication which must be solved if NULL is to
resolve to a special keyword (and not to ((void*)0), as in my proposal).

> We discussed this possibility in the C++ committee years ago There was
> not much support for the idea because it was judged to have
> insufficient utility.

> We can't remove the NULL macro from C++, and we can't remove the use
> of 0 as a null pointer constant. (Virtually every C++ program would
> break, and little C code would be valid in C++.)  The keyword would be
> yet another way to spell "null pointer".  It didn't seem like a big
> enough win.

I can see one real gain with my proposal (or a special keyword):
f( NULL ) will not, and cannot, call f( int ).  Which certainly makes
the use of NULL less confusing (and without the confusion, using NULL
makes the program more readable).  It's a small gain, but my proposal
has a very low cost as well.

Creating a true null is somewhat more complicated -- I would imagine
that with a true null, something like "f( null )" (with the above
definition of f) would be illegal, but I've not begun to do any of the
necessary analysis.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient=E9e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: postmast.root.admi.gov@iname.com (blargg)
Date: 1999/08/14
Raw View
In article <7ov8et$1s0q$1@news.hal-pc.org>, "Greg Brewer"
<nospam.gregb@hal-pc.org> wrote:

> Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote in message
> news:37B2E2E2.3CA3@wanadoo.fr...
> > You are the 34324th person who proposes that.
> >
> > Now, please answer this question: what is the type of NULL ?
>
> Only 34234th, I would have thought is more like 34688th.  ;-)
>
> Seriously, NULL would remain a macro.  The value the NULL resolves to would
> be of type universal pointer.  It would be unique in that it would be the
> only literal value capable of having that type.
>
>    typeof(NULL) x = &anything;   // would be illegal.
>
>   if (typeof(NULL) == typeof(anything) )   // is always false.

What is typeof? Last time I checked, the language didn't allow comparison
of types (the closest it allows is comparison of type_info objects, gotten
with typeid).

Why not make it special in that it has no type, and is not an object?

> The universal pointer can convert to any type of pointer.  No pointer can
> convert to a universal pointer.

This sounds like the opposite of void*. Strange.

> I just had an idea.  I once thought you might designate the null pointer
> with a reserved word like unull; but, I think the literal value &0 would be
> better.  It something that currently gives me an error and involves adding
> no new reserved words that someone may already be using as a variable.
>    #define NULL &0
>
> Come on troops.  Viva &0!

So common. Sugar-coat the proposal at the end saying that "no code using
this would be valid, so we could use this weird syntactic construct to
represent this concept".

Why would &0 be better? It would be a loosening of type-safety. Sure, we
could make any ill-formed program have some valid interpretation for a new
feature. Let's make trying to assign type X to type Y mean something new
if type X can't normally be assigned to type Y.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: David R Tribble <david@tribble.com>
Date: 1999/08/14
Raw View
"Siemel B. Naran" wrote:
>
> Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
> >Greg Brewer wrote:
>
> >> This universal null would be an untyped
> >> pointer that could be promoted to any type of pointer and 0 could
> >> only be an integer.
> >
> >You are the 34324th person who proposes that.
> >
> >Now, please answer this question: what is the type of NULL ?
>
> In the ideal language, NULL would be deprecated.

No, an ideal language would have a true 'null' keyword and the
practice of using integer constants as null pointers would be
deprecated.

-- David R. Tribble, david@tribble.com --
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: Pete Becker <petebecker@acm.org>
Date: 1999/08/14
Raw View
David R Tribble wrote:
>
> "Siemel B. Naran" wrote:
> >
> > In the ideal language, NULL would be deprecated.
>
> No, an ideal language would have a true 'null' keyword and the
> practice of using integer constants as null pointers would be
> deprecated.
>

In an ideal language nothing would be deprecated. Deprecation is a
compromise with the past, something that is only needed in practice, not
in theory.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: Valentin Bonnard <Bonnard.V@wanadoo.fr>
Date: 1999/08/12
Raw View
Greg Brewer wrote:

> (int)0

No 0 is already of type int. Don't cast it to an int, except to
increase confusion.

> This universal null would be an untyped
> pointer that could be promoted to any type of pointer and 0 could only be an
> integer.

You are the 34324th person who proposes that.

Now, please answer this question: what is the type of NULL ?

--

Valentin Bonnard


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: "Greg Brewer" <nospam.gregb@hal-pc.org>
Date: 1999/08/12
Raw View

Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote in message
news:37B2E2E2.3CA3@wanadoo.fr...
> You are the 34324th person who proposes that.
>
> Now, please answer this question: what is the type of NULL ?

Only 34234th, I would have thought is more like 34688th.  ;-)

Seriously, NULL would remain a macro.  The value the NULL resolves to would
be of type universal pointer.  It would be unique in that it would be the
only literal value capable of having that type.
   typeof(NULL) x = &anything;   // would be illegal.

  if (typeof(NULL) == typeof(anything) )   // is always false.

The universal pointer can convert to any type of pointer.  No pointer can
convert to a universal pointer.

I just had an idea.  I once thought you might designate the null pointer
with a reserved word like unull; but, I think the literal value &0 would be
better.  It something that currently gives me an error and involves adding
no new reserved words that someone may already be using as a variable.
   #define NULL &0

Come on troops.  Viva &0!
lol

Greg Brewer




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: clamage@eng.sun.com (Steve Clamage)
Date: 1999/08/13
Raw View
Valentin Bonnard <Bonnard.V@wanadoo.fr> writes:

>> This universal null would be an untyped
>> pointer that could be promoted to any type of pointer and 0 could only be an
>> integer.

>Now, please answer this question: what is the type of NULL ?

It's the same type as "new" in a new-expression. :-)

That is, if you create a language keyword to represent a universal
null pointer, its type would be determined from context. You could
use it the same way in pointer contexts as 0 is used now, except
there would be no ambiguity with an integer 0.

We discussed this possibility in the C++ committee years ago
There was not much support for the idea because it was judged to
have insufficient utility.

We can't remove the NULL macro from C++, and we can't remove
the use of 0 as a null pointer constant. (Virtually every C++
program would break, and little C code would be valid in C++.)
The keyword would be yet another way to spell "null pointer".
It didn't seem like a big enough win.

--
Steve Clamage, stephen.clamage@sun.com
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: sbnaran@uiuc.edu (Siemel B. Naran)
Date: 1999/08/13
Raw View
On 12 Aug 1999 15:22:27 GMT, Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
>Greg Brewer wrote:

>> This universal null would be an untyped
>> pointer that could be promoted to any type of pointer and 0 could only be an
>> integer.
>
>You are the 34324th person who proposes that.
>
>Now, please answer this question: what is the type of NULL ?

In the ideal language, NULL would be deprecated.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]