Erik Max Francis wrote:
....
> > The problem with NULL is it is often defined to 0 which is a int.
>
> In C++, actually, it _must_ be defined as an integral zero.

It must be defined as an integral constant expression with a value of
zero. That's not quite the same thing. For example, it would be
perfectly legal to define it as follows:

#define NULL _some_namespace::_some_class::_some_zere_valued_constant

The lovely thing about using such a definition, is that Koenig lookup
would add _some_namespace and _some_namespace::_some_class to the name
lookup process. Enjoy! :-)

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"James Kuyper Jr." <kuyper@wizard.net> wrote in message news:<3C6876EB.CC397B31@wizard.net>...
 > Peter Koch Larsen wrote:
 > ....
 > > So far as i know, C++ uses 0, not ever NULL. This certainly is what
 >
 > It uses both. NULL is required to be a null pointer constant. 0 is a
 > null pointer constant; but so are many other possible definitions of
 > NULL. However, I can't imagine any reason under the current standard for
 > defining it as anything other than 0. If it weren't for backward
 > compatibility issues, there's lots of ways that definition could be
 > improved upon.
 > ---
 > [ 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.research.att.com/~austern/csc/faq.html                ]

Hi James

I know: NULL is accepted in C++, of course - it is valid C. But the
very idea of using a #define for this kind of purpose is very un
C++-like and thus should not be used. Stroustrup spends some time to
give good arguments for 0 not NULL.

Regards
Peter

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3C684C02.5060004@m.com>, Carlos Moreno
<moreno_at_mochima_dot_com@m.com> wrote:
>> I usually use 0. What's wrong with that?

>Well, I for one think this is one of the (very few) aspects
>in which C++ made a C problem far worse...  :-(
>
>C++ claims to be more strongly typed than C...  Yet it mixes
>a possible value for pointers, with one particular numeric
>value

My own feeling about C++ is that the enhanced C features, one cannot fully
do anything about in view of the problem that C has. Therefore, I think
one should concentrate on straightening those things out in a wholly new
C++ core, and not worry so much about the problems with the C legacy
stuff.

This new C++ core may mainly deal with high level issues. But it is a good
idea to make a new medium (C) level core. But then one should probably
start from scratch, making sure that the C problems do not sneak in. Then
the question is whether it is worth the effort.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

James Kanze wrote:

> Could you please explain how the C++ type conversion rules allow an
> integer 0 to work, but could not be written to allow a ((void*)0) to
> work.

It would seem wasteful to undo the restriction that the C++ Standard
places on conversions to and from void * (which are not present in the C
Standard) in order to allow _more_ conversions to and full null pointer
constants, not less.

--
 Erik Max Francis / max@alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/  \ Laws are silent in time of war.
\__/ Cicero
    Esperanto reference / http://www.alcyone.com/max/lang/esperanto/
 An Esperanto reference for English speakers.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Thorsten Ottosen wrote:
>
> "James Kuyper Jr." <kuyper@wizard.net> wrote in message
> news:3C69CC46.A5A8615B@wizard.net...
....
> > I don't know whether he said that, but it's not correct. The standard
> > does not deprecate NULL; in fact, it uses it in a great many locations.

> OK, so the <cstddef> header defines a NULL macro, but, now I remember

And so do <cstring>, and <ctime>, and <cwchar>, and <clocale>, and
<cstdio>.

> what Stroustrup said:
>
> "In C it has been popular to define a macro NULL to represent the zero
> pointer.
> Because of C++ tighter type checking, the use of plain 0. rather than any
> suggested NULL,
> leads to fewer problems. If you feel you must define NULL, sue
>
> const int NULL = 0;" [TC++PL, special edition, p 88]
>
> I do not feel like defining NULL, and if that statement above does not
> signify that NULL is depricated, then what?

Stroustrup might have deprecated NULL. However, if Stroustrup had said
"NULL is deprecated" rather than "I deprecate NULL", he would by
implication have been saying that it is deprecated by the standard, and
that would not be correct.

> > It even uses NULL in some places where I don't think it should. In
> > several places it says that various functions (mostly in the I/O
> > library) return NULL under certain circumstances. In comparable
> > situations, the C standard usually specifies that the functions returns
> > a null pointer value, which I think is a more appropriate description.
> The fact that some people use it or that it's still in the standard is not
> an argument for that it's not deprecated.

True - the fact that the standard never says that NULL is deprecated is
sufficient. The fact that it's referred to by other parts of the
standard itself when describing non-deprecated facilities of the
standard library is merely supporting evidence.
---
[ 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.research.att.com/~austern/csc/faq.html                ]

Erik Max Francis wrote:
>
> Carlos Moreno wrote:
>
> > void foo (int n);
> >
> > void foo (const char * str);
> >
> > foo(0);   // ambiguity...   (WHAT???  Ambiguity you said??!!)
> >
> > I don't know you, but I find it *very* wrong that the above
> > line is ambiguous...
>
> This problem is no different than using NULL in C:
>
>         foo(NULL);
>
> may raise the same ambiguity, since integral zero is just as much the

How can there be an ambiguity? C doesn't allow overloading. There's only
one possible function signature for foo(), and whatever that signature
is, it allows only one correct way to NULL when passed as argument.
---
[ 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.research.att.com/~austern/csc/faq.html                ]

Greg Comeau wrote:

> In article <3C683DA8.FBCF446F@alcyone.com>,
> Erik Max Francis  <max@alcyone.com> wrote:
>
> > In C++, actually, it _must_ be defined as an integral zero.
>
> Isn't 0L and others allowed too?   The means it can be problematic
> in some cases (just like using 0 or 0L yourself can be).

Right, that's why I said "integral zero" instead of "0."  :-)

--
 Erik Max Francis / max@alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/  \ Laws are silent in time of war.
\__/ Cicero
    Esperanto reference / http://www.alcyone.com/max/lang/esperanto/
 An Esperanto reference for English speakers.
---
[ 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.research.att.com/~austern/csc/faq.html                ]

On 14 Feb 2002 06:37:41 -0500, kanze@gabi-soft.de (James Kanze) wrote:

>Could you please explain how the C++ type conversion rules allow an
>integer 0 to work, but could not be written to allow a ((void*)0) to
>work.

All I'm saying is that it would be quite a significant change to the
standard because currently the standard doesn't have the concept of
pointer constant expressions, only integral constant expressions. I'm
not saying that the change couldn't be made, just that I don't think
it particularly worthwhile.

Tom

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

> Stroustrup might have deprecated NULL. However, if Stroustrup had said
> "NULL is deprecated" rather than "I deprecate NULL", he would by
> implication have been saying that it is deprecated by the standard, and
> that would not be correct.

Obviously we have different interpretations of "depricated".


regards

Thorsten Ottosen



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Erik Max Francis <max@alcyone.com> wrote in message
news:<3C6C0E78.37DF7817@alcyone.com>...
> James Kanze wrote:

> > Could you please explain how the C++ type conversion rules allow
> > an integer 0 to work, but could not be written to allow a
> > ((void*)0) to work.

> It would seem wasteful to undo the restriction that the C++ Standard
> places on conversions to and from void * (which are not present in
> the C Standard) in order to allow _more_ conversions to and full
> null pointer constants, not less.

Nobody is suggesting removing these rules, any more than using integer
0 requires removing rules against conversions between pointers and
integers.

The current C++ rules do NOT allow converting an integer to a pointer
(except by means of a reinterpret cast).  It takes special magic for 0
to work as a null pointer constant.  Why is this special magic
acceptable for 0, but not for ((void*)0)?

--
James Kanze                                   mailto:kanze@gabi-soft.de
Beratung in objektorientierer Datenverarbeitung --
                             -- Conseils en informatique orientie objet
Ziegelh|ttenweg 17a, 60598 Frankfurt, Germany, Til.: +49 (0)69 19 86 27
---
[ 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.research.att.com/~austern/csc/faq.html                ]

tom_usenet wrote:
>
> On 14 Feb 2002 06:37:41 -0500, kanze@gabi-soft.de (James Kanze) wrote:
>
> >Could you please explain how the C++ type conversion rules allow an
> >integer 0 to work, but could not be written to allow a ((void*)0) to
> >work.
>
> All I'm saying is that it would be quite a significant change to the
> standard because currently the standard doesn't have the concept of
> pointer constant expressions, only integral constant expressions. I'm

The relevant thing is not integral constant expressions in general, but
rather, the special subset of those expressions known as null pointer
constants. There are special rules for null pointer constants, and the
issue is whether or not C++ should revert to the C practice, which is to
allow casts to 'void *' in null pointer constants (which means that C
null pointer constants are NOT a subset of integral constant
expressions). This would be a significant change, and probably a bad
idea for C++, but there is a LOT of existing C experience to fall back
on, if the decision were made to actually do this.

The standard does have the concept of pointer constant expressions. The
term it actually uses is address constant expressions, but these are
pointers, and constant expressions, so I think they fit your meaning.
They're defined in 5.19p4. However, they are significant only in that
they may legally be used in the initialization of a non-local static
object. The special rules for null pointer constants don't apply to
them. That's good, because address pointer expressions can't have a null
value. They are required to point at an actual static object, string
literal, or function.  Pointers are required to compare equal if they
point at the same object or function, and null pointers are prohibited
from comparing equal to the pointer to any actual object or function.
Therefore, (void*)0 is not an address constant expression, despite being
both a pointer and a constant expression.

What's needed is a special identifier that automatically converts to a
null pointer of the needed type, but unlike 0, can never be used as an
integer except by the use of an explicit type conversion. Like 0, it
should be illegal to attempt to take the address of this identifier. You
can achieve all of these features with a suitably defined template.

However, to avoid breaking existing code, the identifier with these
properties can't be NULL, or the expansion of a macro named NULL, which
makes things annoying.
---
[ 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.research.att.com/~austern/csc/faq.html                ]

Atle Slagsvold wrote:
>
> In the next C++ standard NULL should be replaced with another
> identifier. Maybe std::null?
> std::null have the same use as NULL but it has a pointertypr.
> The problem with NULL is it is often defined to 0 which is a int.
> When used together with template functions it matches ordinary types and not
> pointers.

This is a recently-discussed topic.
http://groups.google.com/groups?threadm=Pine.LNX.4.33.0111270001060.9483-100000%40csl

--
Sungbom Kim <musiphil@bawi.org>
---
[ 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.research.att.com/~austern/csc/faq.html                ]

Peter Koch Larsen wrote:
....
> So far as i know, C++ uses 0, not ever NULL. This certainly is what

It uses both. NULL is required to be a null pointer constant. 0 is a
null pointer constant; but so are many other possible definitions of
NULL. However, I can't imagine any reason under the current standard for
defining it as anything other than 0. If it weren't for backward
compatibility issues, there's lots of ways that definition could be
improved upon.
---
[ 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.research.att.com/~austern/csc/faq.html                ]

Thorsten Ottosen wrote:
>
> I recall Stroustrup saying, that NULL is deprecated. Use '0' . That's the

I don't know whether he said that, but it's not correct. The standard
does not deprecate NULL; in fact, it uses it in a great many locations.

It even uses NULL in some places where I don't think it should. In
several places it says that various functions (mostly in the I/O
library) return NULL under certain circumstances. In comparable
situations, the C standard usually specifies that the functions returns
a null pointer value, which I think is a more appropriate description.
---
[ 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.research.att.com/~austern/csc/faq.html                ]

On 10 Feb 2002 16:02:52 GMT, "Atle Slagsvold" <atleslag@online.no>
wrote:

>In the next C++ standard NULL should be replaced with another
>identifier. Maybe std::null?

Scott Meyers, Effective C++, Item 25.

As Scott Meyers puts it, "a sight to behold".

const
class {
public:
 template<class T>
  operator T*() const
  { return 0; }

 template< class C, class T>
  operator T C::*() const
  { return 0; }

private:
 void operator&() const;
} NULL;


God help you if you're using a compiler that doesn't take member
function templates. :-)
Alex Pavloff
Software Engineer
Eason Technology
---
[ 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.research.att.com/~austern/csc/faq.html                ]

> I usually use 0. What's wrong with that?

And.... I use 0 for false, and 1 for true.
---
[ 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.research.att.com/~austern/csc/faq.html                ]

Atle Slagsvold wrote:

> In the next C++ standard NULL should be replaced with another
> identifier. Maybe std::null?
> std::null have the same use as NULL but it has a pointertypr.

But a pointer to what type?  The problem with introducing a null keyword
is that it really wouldn't resolve the underlying problem, which is that
we need a null pointer to have arbitrary type -- whatever type we mean
at the time.  Conceivably a null keyword could avoid integer-and-pointer
ambiguity, but that's only part of the problem:

 int f(int *);
 int f(int (*)());
 int f(int (C::*)());

If we have a null keyword and write f(null), which one gets called?  If
it's ambiguous (which it must be), what did that really gain us?  This
is made even more ugly by the fact that data pointers, function
pointers, and member function pointers are not interconvertible, so
really our null pointer constant needs to be "cheat."

Whether you use 0 or NULL to represent a null pointer constant, there
are still situations where you have no choice but to use an explicit
cast.  The most obvious case is in varargs -- because at the time the
call is constructed the compiler can't know what pointer type we mean,
and it's quite possible that pointer types could be represented
differently.

If we have, say, a function which takes as C-style format string and a
list of pointers of varying types (potentially including null pointers),
how do we represent that?

 int g(const std::string &format, ...);

 g("$i $c $d $fvRv", null, null, null, null);

won't work, because null can't convert itself to the right type.  We
need to use explicit casts:

 g("$i $c $d $fvRv", static_cast<int *>(null),
       static_cast<char *>(null),
       static_cast<double *>(null),
       static_cast<void (*)()>(null));

The only alternative is to do some magic with the null keyword that
makes it pass in a special sentinel to varargs functions which is then
translated at runtime to the right type.  This just introduces problems.

> The problem with NULL is it is often defined to 0 which is a int.

In C++, actually, it _must_ be defined as an integral zero.

--
 Erik Max Francis / max@alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/  \ Laws are silent in time of war.
\__/ Cicero
    Esperanto reference / http://www.alcyone.com/max/lang/esperanto/
 An Esperanto reference for English speakers.
---
[ 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.research.att.com/~austern/csc/faq.html                ]

Carlos Moreno <moreno_at_mochima_dot_com@m.com> wrote in message news:<3C684C02.5060004@m.com>...
> Hans Aberg wrote:
>
> >
> > I usually use 0. What's wrong with that?
>
>
> Well, I for one think this is one of the (very few) aspects
> in which C++ made a C problem far worse...  :-(
>
> C++ claims to be more strongly typed than C...  Yet it mixes
> a possible value for pointers, with one particular numeric
> value -- When I see 0 in my code, I would really like to
> think that it can only mean one thing...  A numeric value
> and a "magic value" for a pointer are two things sooooooo
> different that it offends me that they're spelled exactly
> the same in code  :-(
>
> It sounds as though we're formalizing a common misconception
> (thinking that NULL is a pointer containing the memory
> location 0 -- i.e., memory address 0)...  So, instead of
> completely divorcing both possibilities so that no-one
> ever again mixes them and confuses them, no...  We make
> them equivalent...  ARRRRGHHH!!!!!
>
>
> void foo (int n);
>
>
> void foo (const char * str);
>
>
> foo(0);   // ambiguity...   (WHAT???  Ambiguity you said??!!)
>
> I don't know you, but I find it *very* wrong that the above
> line is ambiguous...

How about this:

#include <iostream>

using namespace std;

struct C {
  C* f(C*) { cout << "C::f(C*)" << endl; return 0; }
  C* f(C*,C*) { cout << "C::f(C*,C*)" << endl; return 0; }
};

void f(char) { cout << "f(char)" << endl; }
void f(char*) { cout << "f(char*)" << endl; }
void f(const char*) { cout << "f(const char*)" << endl; }
void f(int) { cout << "f(int)" << endl; }
void f(int*) { cout << "f(int*)" << endl; }
void f(int**) { cout << "f(int**)" << endl; }
void f(float*) { cout << "f(float*)" << endl; }
void f(float**) { cout << "f(float**)" << endl; }
void f(int(*)()) { cout << "f(int(*)())" << endl; }
void f(int(**)()) { cout << "f(int(**)())" << endl; }
void f(C*) { cout << "f(C*)" << endl; }
void f(C**) { cout << "f(C**)" << endl; }
void f(C*(C::*)(C*)) { cout << "f(C*(C::*)(C*))" << endl; }
void f(C*(C::**)(C*)) { cout << "f(C*(C::**)(C*))" << endl; }
void f(C*(C::*)(C*,C*)) { cout << "f(C*(C::*)(C*,C*))" << endl; }
void f(C*(C::**)(C*,C*)) { cout << "f(C*(C::**)(C*,C*))" << endl; }

int blabla() { cout << "blabla" << endl; return 0; }

template< class T >
T* null_ptr()
{ return 0; }

template< class T >
T null_fun()
{ return 0; }

int main()
{
  int(*func)() = &blabla;
  int(**pfunc)() = &func;
  func();
  (*pfunc)();
  C c;
  C*(C::*mfunc)(C*) = &C::f;
  C*(C::**pmfunc)(C*) = &mfunc;
  (c.*mfunc)(&c);
  (c.**pmfunc)(&c);
  f('\0');
  f(null_ptr<char>());
  f(null_ptr<const char>());
  f(0);
  f(null_ptr<int>());
  f(null_ptr<int*>());
  f(null_ptr<float>());
  f(null_ptr<float*>());
  f(null_fun<int(*)()>()); f(func);
  f(null_fun<int(**)()>());f(pfunc);
  f(null_ptr<int(*)()>()); f(pfunc);
  f(null_ptr<C>());
  f(null_ptr<C*>());
  cout << "---" << endl;
  f(null_fun<C*(C::*)(C*)>()); f(mfunc);
  f(null_fun<C*(C::**)(C*)>());f(pmfunc);
  f(null_ptr<C*(C::*)(C*)>()); f(pmfunc);
  cout << "---" << endl;
  f(null_fun<C*(C::*)(C*,C*)>());
  f(null_fun<C*(C::**)(C*,C*)>());
  return 0;
}

regards,
alexander.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Carlos Moreno wrote:

> void foo (int n);
>
> void foo (const char * str);
>
> foo(0);   // ambiguity...   (WHAT???  Ambiguity you said??!!)
>
> I don't know you, but I find it *very* wrong that the above
> line is ambiguous...

This problem is no different than using NULL in C:

 foo(NULL);

may raise the same ambiguity, since integral zero is just as much the
null pointer constant in C that it is in C++.  (In C, NULL _may_ be
defined as (void *) 0 as well, but it does not have to be, and you
cannot relying on it being so to help you out of this ambiguity in
portable code.)

Besides, a null pointer constant, regardless of whether you call it NULL
or 0, won't help you in this case:

 void bar(const char *);
 void bar(const int *);

 bar(0); // or bar(NULL);

You need to use an explicit cast (static_cast in C++, usual cast
notation in C); even proposals for introducing new keywords won't help
you here.

--
 Erik Max Francis / max@alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/  \ Laws are silent in time of war.
\__/ Cicero
    Esperanto reference / http://www.alcyone.com/max/lang/esperanto/
 An Esperanto reference for English speakers.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"James Kuyper Jr." <kuyper@wizard.net> wrote in message
news:3C69CC46.A5A8615B@wizard.net...
> Thorsten Ottosen wrote:
> >
> > I recall Stroustrup saying, that NULL is deprecated. Use '0' . That's
the
>
> I don't know whether he said that, but it's not correct. The standard
> does not deprecate NULL; in fact, it uses it in a great many locations.
OK, so the <cstddef> header defines a NULL macro, but, now I remember
what Stroustrup said:

"In C it has been popular to define a macro NULL to represent the zero
pointer.
Because of C++ tighter type checking, the use of plain 0. rather than any
suggested NULL,
leads to fewer problems. If you feel you must define NULL, sue

const int NULL = 0;" [TC++PL, special edition, p 88]

I do not feel like defining NULL, and if that statement above does not
signify that NULL is depricated, then what?

> It even uses NULL in some places where I don't think it should. In
> several places it says that various functions (mostly in the I/O
> library) return NULL under certain circumstances. In comparable
> situations, the C standard usually specifies that the functions returns
> a null pointer value, which I think is a more appropriate description.
The fact that some people use it or that it's still in the standard is not
an argument for that it's not deprecated. Lots of deprecated C++ stuff
can be used by someone if he wants to.

Best regards

Thorsten Ottosen, Aalborg University





      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3C683DA8.FBCF446F@alcyone.com>,
Erik Max Francis  <max@alcyone.com> wrote:
>> The problem with NULL is it is often defined to 0 which is a int.
>
>In C++, actually, it _must_ be defined as an integral zero.

Isn't 0L and others allowed too?   The means it can be problematic
in some cases (just like using 0 or 0L yourself can be).
--
Greg Comeau  GA BETA:4+ New Windows Backends  PLUS 'export' beta online!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"James Kuyper Jr." <kuyper@wizard.net> wrote in message
news:<3C6876EB.CC397B31@wizard.net>...
> Peter Koch Larsen wrote:
> ....
> > So far as i know, C++ uses 0, not ever NULL. This certainly is what
>
> It uses both. NULL is required to be a null pointer constant. 0 is a
> null pointer constant; but so are many other possible definitions of
> NULL. However, I can't imagine any reason under the current standard for
> defining it as anything other than 0.

I can. I would say that 'false' is a better candidate, because NULL pointer
looks more a 'logical' than a 'numerical' entity.

[snip]

Radoslav Getov

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Carlos Moreno" <moreno_at_mochima_dot_com@m.com> wrote in message
news:3C684C02.5060004@m.com...
<SNIP>
> void foo (int n);
>
>
> void foo (const char * str);
>
>
> foo(0);   // ambiguity...   (WHAT???  Ambiguity you said??!!)
>
> I don't know you, but I find it *very* wrong that the above
> line is ambiguous...

But it's not ambiguous. C++ overloading rules require the compiler to
resolve the call to the int version.  The int version is considered the
better match because the type of the parameter matches exactly whereas the
const char* version requires a conversion.




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Thorsten Ottosen wrote:
>
> I recall Stroustrup saying, that NULL is deprecated. Use '0' . That's the
> standard way.

Stroustrup never said that.  He said that many implementations (at the time he
made that statement) misdefine NULL in C++, so he prefers to use 0.  Frankly,
I've not encountered such a misimplementation in the past five years.
---
[ 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.research.att.com/~austern/csc/faq.html                ]

tom_usenet@hotmail.com (tom_usenet) wrote in message
news:<3c67c011.7708984@news.easynet.co.uk>...
> On 10 Feb 2002 16:02:52 GMT, "Atle Slagsvold" <atleslag@online.no>
> wrote:

> >In the next C++ standard NULL should be replaced with another
> >identifier. Maybe std::null?  std::null have the same use as NULL
> >but it has a pointertypr.

> Yes, but what pointer type?

If we are creating a new keyword, a new, special pointer type.

> void* is useless because of the C++ type conversion rules.

Could you please explain how the C++ type conversion rules allow an
integer 0 to work, but could not be written to allow a ((void*)0) to
work.

> Perhaps a non-pointer type might be useful:

> namespace std
> {

> struct null_t
> {
>  template <class T>
>  operator T*() const
>  {
>   return 0;
>  }
> };

> extern null_t const null;
>
> }

> However, that isn't going to behave quite the same as NULL (or
> 0). It won't help in your overloading example at all.


> >The problem with NULL is it is often defined to 0 which is a int.

> It has to be an null pointer constant, which has to have an integral
> rather than pointer type.

> >When used together with template functions it matches ordinary
> >types and not pointers.

> Right. You can easily cast it:

> (void*)0
> (int*)0

> or whatever type you want your null to have.

> >The old NULL would still be possible to use, but all new C++ should
> >use std::null.

> I'm not sure this is possible without changing the language. We
> removed the conversion from void* to T*, but the change you propose
> will need to reinstate this for the constant (void*)0. Which means
> that pointer constant expressions will have to be added to the
> language (currently only integral constant expressions exist). The
> ramifications seem to great to me to be bothered with it.

The template above doesn't have any problem with conversions to any
pointer type.  With a few additions (a private copy constructor), it
can be made to generate an error when being passed to a vararg without
a cast, which is also, IMHO, a desired feature.  If several pointer
overloads of a function exist, it will cause the call to be ambiguous;
if only one exists, it will choose it.

It seems like a reasonably good solution to me.

--
James Kanze                                   mailto:kanze@gabi-soft.de
Beratung in objektorientierer Datenverarbeitung --
                             -- Conseils en informatique orientie objet
Ziegelh|ttenweg 17a, 60598 Frankfurt, Germany, Til.: +49 (0)69 19 86 27
---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message
news:<a48r4a$cj1$1@sunsite.dk>...
> I recall Stroustrup saying, that NULL is deprecated. Use '0'. That's
> the standard way.

The standard allows both NULL and 0.  And in every place I've worked
which has had one, the coding guidelines required NULL.

--
James Kanze                                   mailto:kanze@gabi-soft.de
Beratung in objektorientierer Datenverarbeitung --
                             -- Conseils en informatique orientie objet
Ziegelh|ttenweg 17a, 60598 Frankfurt, Germany, Til.: +49 (0)69 19 86 27
---
[ 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.research.att.com/~austern/csc/faq.html                ]

In the next C++ standard NULL should be replaced with another
identifier. Maybe std::null?
std::null have the same use as NULL but it has a pointertypr.
The problem with NULL is it is often defined to 0 which is a int.
When used together with template functions it matches ordinary types and not
pointers.
Example:

#include <iostream>

using namespace std;

template <class X>
void func(X *)
{
    cout<<"Pointer version called"<<endl;
}

template <class X>
void func(const X &in)
{
    cout << "general version called"<<endl;
}

int main()
{
    void *a=NULL;
    func(a);
    func(NULL);
}

Here I would like to get
Pointer version called
Pointer version called
but I get
Pointer version called
general version called

The old NULL would still be possible to use, but all new C++ should use
std::null.

Atle


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Atle Slagsvold wrote:
>
> In the next C++ standard NULL should be replaced with another
> identifier. Maybe std::null?
> std::null have the same use as NULL but it has a pointertypr.

   There are a lot of pointer types and they are incompatible with each
other. Pointer to function, pointer to member, pointer to void, ...
Untyped NULL can be used in any of these contexts, while you'll probably
need individual typed std::null for every possible use (and they are
countless, just think of how many types of function pointer one might
need).

Igor

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Besides C compatibility imposes the idioms
char *p;

p = 0;
if ( p == 0 )

as being equivalent to p = NULL; and if ( p == NULL )

"Igor A. Goussarov" <igusarov@akella.com> a    crit dans le message de news:
3C66AAB5.9F0BE121@akella.com...
> Atle Slagsvold wrote:
> >
> > In the next C++ standard NULL should be replaced with another
> > identifier. Maybe std::null?
> > std::null have the same use as NULL but it has a pointertypr.
>
>    There are a lot of pointer types and they are incompatible with each
> other. Pointer to function, pointer to member, pointer to void, ...
> Untyped NULL can be used in any of these contexts, while you'll probably
> need individual typed std::null for every possible use (and they are
> countless, just think of how many types of function pointer one might
> need).
>
> Igor
>
> ---
> [ 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.research.att.com/~austern/csc/faq.html                ]
>


---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Igor A. Goussarov" <igusarov@akella.com> wrote in message news:<3C66AAB5.9F0BE121@akella.com>...
> Atle Slagsvold wrote:
> >
> > In the next C++ standard NULL should be replaced with another
> > identifier. Maybe std::null?
> > std::null have the same use as NULL but it has a pointertypr.
>
>    There are a lot of pointer types and they are incompatible with each
> other. Pointer to function, pointer to member, pointer to void, ...
> Untyped NULL can be used in any of these contexts, while you'll probably
> need individual typed std::null for every possible use (and they are
> countless, just think of how many types of function pointer one might
> need).

... or you need a std::null_t which has a template conversion to
T*, T::U*, T(*)(), etcetera. That still doesn't solve all problems -
with a function template foo(PTR* ptr), foo(std::null) still won't
work, but that's Ok. std::null effectively is an untyped pointer,
so it shouldn't have one particular pointer type.

HTH,
--
Michiel Salters

---
[ 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.research.att.com/~austern/csc/faq.html                ]

just off the top of my head... and thinking out aloud, why not:

namespace std{
class Null
{
    template <typename T> operator T*() { return reinterpret_cast<T*>(0); }
    template <typename T, typelist U> operator T(*)(U) () { return
reinterpret_cast<T(*)(U)>(0); }
    ...
};
const Null null;
}

assuming the mythological typelist template keyword was added to the
language, it just might work :P
actually... I'd be very keen to see typelist, or some other construct that
allows a variable number of arguments in a template list make the standard,
in order to make writing generic code that munges functions into functions
actually become reasonable without listing off stacks off lines for all the
variations...

"Igor A. Goussarov" <igusarov@akella.com> wrote in message
news:3C66AAB5.9F0BE121@akella.com...
> Atle Slagsvold wrote:
> >
> > In the next C++ standard NULL should be replaced with another
> > identifier. Maybe std::null?
> > std::null have the same use as NULL but it has a pointertypr.
>
>    There are a lot of pointer types and they are incompatible with each
> other. Pointer to function, pointer to member, pointer to void, ...
> Untyped NULL can be used in any of these contexts, while you'll probably
> need individual typed std::null for every possible use (and they are
> countless, just think of how many types of function pointer one might
> need).
>
> Igor
>
> ---
> [ 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.research.att.com/~austern/csc/faq.html                ]
>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1013416168 27664 127.0.0.1 (11 Feb 2002 08:29:28
GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: 11 Feb 2002 08:29:28 GMT
Content-Length: 1316
ReSent-Date: Mon, 11 Feb 2002 07:57:11 -0800 (PST)
ReSent-From: Steve Clamage <clamage@eng.sun.com>
ReSent-To:  <c++-submit@netlab.cs.rpi.edu>
ReSent-Subject: Re: replace NULL
ReSent-Message-ID: <Pine.SOL.4.33.0202110757110.4152@taumet>

"Atle Slagsvold" <atleslag@online.no> wrote in message
news:<EnT88.2603$HL2.57845@news2.ulv.nextra.no>...
> In the next C++ standard NULL should be replaced with another
> identifier. Maybe std::null?
> std::null have the same use as NULL but it has a pointertypr.
> The problem with NULL is it is often defined to 0 which is a int.
> When used together with template functions it matches ordinary types and not
> pointers.
> Example:
>
> #include <iostream>
>
> using namespace std;
>
> template <class X>
> void func(X *)
> {
>     cout<<"Pointer version called"<<endl;
> }
>
> template <class X>
> void func(const X &in)
> {
>     cout << "general version called"<<endl;
> }
>
> int main()
> {
>     void *a=NULL;
>     func(a);
>     func(NULL);
> }
>
> Here I would like to get
> Pointer version called
> Pointer version called
> but I get
> Pointer version called
> general version called
>

Hi Atle

So far as i know, C++ uses 0, not ever NULL. This certainly is what
Stroustrup writes in one of his books. Regarding your example, my guts
say that your compiler is correct, considering the probable definition
of null.
You could use a template or a #define to get a properly typed null in
those cases (such as your example above) where it may not be quite
obvious what "0" should mean.

Regards
Peter



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

> In the next C++ standard NULL should be replaced with another
> identifier. Maybe std::null?

You mean kind of Java-style then.  If it was going to become as widespread
as you seem to envisage I'd be tempted to save my fingers and just go for
null.

> std::null have the same use as NULL but it has a pointertypr.
> The problem with NULL is it is often defined to 0 which is a int.
> When used together with template functions it matches ordinary types and
not
> pointers.

<<snip>>

What pointer would your std::null be though?  The only sensible option would
be void*, but often NULL needs casting anyway - if you've got:

void func(void*);
void func(someclass*);

then whatever you use for your null surely you'll generally want to write it
as a cast so it is clear which function you are using.  Interesting
Stroustrup advocated the use of 0 rather than NULL as he seemed to consider
NULL a leftover from C, though I have always been taught to avoid having
unclear "magical" numbers in my programs, so NULL seems like a good idea to
me in that respect.






      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In comp.lang.c++.moderated Atle Slagsvold <atleslag@online.no> wrote:
> std::null have the same use as NULL but it has a pointertypr.
> The problem with NULL is it is often defined to 0 which is a int.

Defining NULL as 0 is not the worst of all choices if I am not mistaken.
Of course, things like '0' or '3-3' would be ok, too, but I'd consider this
as 'obfuscation'.

> int main()
> {
>     void *a=NULL;
>     func(a);
>     func(NULL);
> }
>
> Here I would like to get
> Pointer version called
> Pointer version called
> but I get
> Pointer version called
> general version called

But 'NULL' should remain a null pointer constant, i.e. an integral value, if
you want it to use as a 'real pointer' you need to convert it.

Andre'

--
Andr   P  nitz .............................................. poenitz@gmx.de



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Some time ago, "Atle Slagsvold" <atleslag@online.no> wrote:
>
> In the next C++ standard NULL should be replaced with another
> identifier. Maybe std::null?

There's no easy way to make it with the current C++.
You can try with this (possibly with some enhancements):

namespace std
{
 class StdNull
 {
 public:
  template<typename T>
  operator T*()
  {
   return (T*)0;
  }
 };

 // or something, just create the object 'null'
 static StdNull null;
}

but this will not resolve your overloads as you want. The only gain is that:

void foo(int i);

will not be called with foo(std::null);
See Effective C++, Item 25 for more ramblings on this.

Probably new keyword would be needed to fully accomplish the correct resolution,
but then it could not be scoped in any namespace, even in std.

Cheers,

--
Maciej Sobczak
http://www.maciejsobczak.com



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <EnT88.2603$HL2.57845@news2.ulv.nextra.no>, "Atle Slagsvold"
<atleslag@online.no> wrote:

>In the next C++ standard NULL should be replaced with another
>identifier. Maybe std::null?

I usually use 0. What's wrong with that?

I think that a defined name "null" might be used for a library polymorphic
hierarchy. Thus:
  class object_root { .. }; // Other classes derive from this.

  class object { // Maintains a polymorphic pointer to object_root hierarchy.
     object_root* data__;
  public:
     ...
  };

  const object null;  // The null reference.

This will then have all the high level properties that people usually ask
for when asking for an improved NULL object.

Alternative words to "null" might be "none" or "nowhere".

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

On 10 Feb 2002 16:02:52 GMT, "Atle Slagsvold" <atleslag@online.no>
wrote:

>
>In the next C++ standard NULL should be replaced with another
>identifier. Maybe std::null?
>std::null have the same use as NULL but it has a pointertypr.

Yes, but what pointer type? void* is useless because of the C++ type
conversion rules.

Perhaps a non-pointer type might be useful:

namespace std
{

struct null_t
{
 template <class T>
 operator T*() const
 {
  return 0;
 }
};

extern null_t const null;

}

However, that isn't going to behave quite the same as NULL (or 0). It
won't help in your overloading example at all.

>The problem with NULL is it is often defined to 0 which is a int.

It has to be an null pointer constant, which has to have an integral
rather than pointer type.

>When used together with template functions it matches ordinary types and not
>pointers.

Right. You can easily cast it:

(void*)0
(int*)0

or whatever type you want your null to have.

>
>The old NULL would still be possible to use, but all new C++ should use
>std::null.

I'm not sure this is possible without changing the language. We
removed the conversion from void* to T*, but the change you propose
will need to reinstate this for the constant (void*)0. Which means
that pointer constant expressions will have to be added to the
language (currently only integral constant expressions exist). The
ramifications seem to great to me to be bothered with it.

Tom



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

I recall Stroustrup saying, that NULL is deprecated. Use '0' . That's the
standard way.

Kind regards

Thorsten Ottosen, Aalborg University DK




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hans Aberg wrote:

>
> I usually use 0. What's wrong with that?


Well, I for one think this is one of the (very few) aspects
in which C++ made a C problem far worse...  :-(

C++ claims to be more strongly typed than C...  Yet it mixes
a possible value for pointers, with one particular numeric
value -- When I see 0 in my code, I would really like to
think that it can only mean one thing...  A numeric value
and a "magic value" for a pointer are two things sooooooo
different that it offends me that they're spelled exactly
the same in code  :-(

It sounds as though we're formalizing a common misconception
(thinking that NULL is a pointer containing the memory
location 0 -- i.e., memory address 0)...  So, instead of
completely divorcing both possibilities so that no-one
ever again mixes them and confuses them, no...  We make
them equivalent...  ARRRRGHHH!!!!!


void foo (int n);


void foo (const char * str);


foo(0);   // ambiguity...   (WHAT???  Ambiguity you said??!!)

I don't know you, but I find it *very* wrong that the above
line is ambiguous...

Carlos
--
---
[ 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.research.att.com/~austern/csc/faq.html                ]