In article <CK96Mw.F03@microsoft.com> jimad@microsoft.com (Jim Adcock)
writes:

|> In article <KANZE.94Jan20175536@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
|> |Today, there is a significant commercial market for C++; if the header
|> |files for C++ define NULL as '(void*)0', then a complaint to your
|> |vendor is in order.  In fact, I know of no current implementation
|> |where this is the case.  So there is no *technical* reason not to use
|> |NULL.

|> On the contrary, there ARE good *technical* reasons why not to use NULL.
|> To what extent these *technical* reasons are applicable to any
|> particular C++ users varies -- but please don't claim they don't
|> exist.  I agree that there is no good reason why any C++ header file
|> should define NULL to be (void*)0.  However, there remains perfectly
|> good technical reasons why ***C*** header files define NULL to be
|> (void*)0 and it is exceedingly common to find C header files which
|> do so.  Now you know and I know that NULL is suppose to only
|> be defined in stddef.h and the way one gets a definition of NULL
|> is by including stddef.h.  BUT bazillions of C programmers, including
|> those who write many of the best know C commercially available libraries
|> [not just C standard libaries!] DON'T know that NULL is suppose to come
|> from stddef.h and don't care and thus #define NULL to be anything
|> they d*rned well please.

And in doing so, they make themselves incompatible with a lot of the
other libraries, which include stddef.h, and introduce a (possibly)
different definition.  As for this being frequent practice, I know of
only one library which does so, and it is documented as being
deprecated, and replaced (completely) by one which doesn't.

|> Further, even if they did know or care,
|> the stddef.h that these C libraries need to work correctly is different
|> from the stddef.h that C++ code needs to work correctly.

If the library is incompatible with most ISO C header files, I think
that compatibility with my C++ programs is the least of their
problems.

As I said, I know of only one such library.  (But note well, Jim
Adcock and I frequent different worlds.  I do 99% of my work under
Unix, whereas judging from Jim's email address, his company prefers a
different OS.  If things are really as bad as Jim paints them in the
MS-DOS world, ... yet another reason to avoid it.)

|> The bottom
|> line then is that if you write C++ code using NULL, and then ever need
|> to use any C libaries and header files written by C programmers, you
|> stand a very large chance of getting toasted.

The problem is worse.  Even if *you* don't use NULL, if these
libraries and headers need *their* version of NULL, what happens when
their versions are not compatible.

|> Your C++ code is very
|> likely to pick up their definition of NULL overridding the C++ definition
|> of NULL, and all of a sudden megamount of your C++ code is going to
|> compile with type incompatibility error messages.  My advice is to
|> leave C programmers their NULL, and get on with C++.  If you never
|> use any C code, then you can do what you like.

I have a sneaking feeling that this insistence on NULL has to do with
compatibility across models of compilation (small, medium and large).
And that it depends not on the library defining NULL themselves, but
on it counting on the fact that 'sizeof( NULL )' will give them the
number of bytes in a pointer.  So Jim may actually have a point.  I've
always handled this with a conditional compilation under MS-DOS, but
to each his own...  Given that it is practically an MS-DOS standard in
C to define NULL as '(void*)0' (since Microsoft does it), people who
think the world ends at 640Kbytes may actually be using this fact.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <KANZE.94Jan20175536@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
|Today, there is a significant commercial market for C++; if the header
|files for C++ define NULL as '(void*)0', then a complaint to your
|vendor is in order.  In fact, I know of no current implementation
|where this is the case.  So there is no *technical* reason not to use
|NULL.

On the contrary, there ARE good *technical* reasons why not to use NULL.
To what extent these *technical* reasons are applicable to any
particular C++ users varies -- but please don't claim they don't
exist.  I agree that there is no good reason why any C++ header file
should define NULL to be (void*)0.  However, there remains perfectly
good technical reasons why ***C*** header files define NULL to be
(void*)0 and it is exceedingly common to find C header files which
do so.  Now you know and I know that NULL is suppose to only
be defined in stddef.h and the way one gets a definition of NULL
is by including stddef.h.  BUT bazillions of C programmers, including
those who write many of the best know C commercially available libraries
[not just C standard libaries!] DON'T know that NULL is suppose to come
from stddef.h and don't care and thus #define NULL to be anything
they d*rned well please.  Further, even if they did know or care,
the stddef.h that these C libraries need to work correctly is different
from the stddef.h that C++ code needs to work correctly.  The bottom
line then is that if you write C++ code using NULL, and then ever need
to use any C libaries and header files written by C programmers, you
stand a very large chance of getting toasted.  Your C++ code is very
likely to pick up their definition of NULL overridding the C++ definition
of NULL, and all of a sudden megamount of your C++ code is going to
compile with type incompatibility error messages.  My advice is to
leave C programmers their NULL, and get on with C++.  If you never
use any C code, then you can do what you like.

In article <2hmh88$qjl@euas20.eua.ericsson.se> euamts@eua.ericsson.se
(Mats Henricson) writes:

|> In article CoM@netcom.com, sbarton@netcom.com (Sharon Barton) writes:
|> >Can anyone tell me why Thomas Plum and Donald Saks recommend using
|> >0 to initialize pointers instead of NULL in their C++ Programming
|> >Guidelines book?  This isn't consistent with ANSI C.  Isn't C++
|> >based on ANSI C?

|> I think it was because when that book was written, many compilers defined
|> NULL the way C compilers often does it: ((void*) 0). This can give you a
|> LOT of problems, so in C++ this was changed. NULL can in C++ be defined as
|> 0, OL, or something else, but NOT as ((void*) 0). The recommendation was
|> important then and is probably still important for some, but will hopefully
|> not be important in the future.

The current draft of the ISO standard is quite clear: section 4.6
defines a constant expression that evaluates to zero as a null pointer
constant, and somewhere in chapter 17 (my copy of the working papers
is at home), it is stated that NULL is defined as an
implementation-dependant C++ null pointer constant.

So this will *not* be a problem with any conforming compiler.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <1994Jan21.143631.8055@vlsi.polymtl.ca>
linh@info.polymtl.ca (Linh Minh Hong Dang) writes:

|> How about...

|> template<class T>
|> class Null {
|>   public:
|>     static T* Ptr()   { return (T*)0; }
|> };

|> //...

|> main()
|> {
|>     double* dp;
|>     //...

|>     dp = Null<double>::Ptr();
|>     //...
|>     if (dp == Null<double>::Ptr())
|>     //...
|> }

Even simpler:

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

    // ...

        double*  dp = Null< double >() ;
        if ( dp == Null< double >() )

Now if I could only get rid of the '()'.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <sbartonCJwGnu.CoM@netcom.com> sbarton@netcom.com (Sharon
Barton) writes:

|> Can anyone tell me why Thomas Plum and Donald Saks recommend using
|> 0 to initialize pointers instead of NULL in their C++ Programming
|> Guidelines book?  This isn't consistent with ANSI C.  Isn't C++
|> based on ANSI C?

Here we go again:-(.

Historically, a number of early C++ compilers (well, at least one)
were really just front-ends for the C compiler.  In addition, since
the commercial market was not worth the effort, the simple solution of
just enrobing the standard C header files in extern "C" { ... } was
adapted.

In C, NULL may be legally defined as '(void*)0', and some systems
actually do this.  This works well in C, since a void* can be assigned
to any type of pointer.  On the other hand, C++ does not allow an
implicit cast *from* void*, and this lead to the fact that you could
not assign NULL to a pointer (nor compare a pointer to NULL, nor...).

Today, there is a significant commercial market for C++; if the header
files for C++ define NULL as '(void*)0', then a complaint to your
vendor is in order.  In fact, I know of no current implementation
where this is the case.  So there is no *technical* reason not to use
NULL.

The question of style remains.  I have many years of C experience, and
in all of the companies, the house style was to use NULL.  I find that
information is missing when 0 is used; the type system is being
abused.  In fact, until the last big discussion of this on the net, I
was convinced that without the obslete technical reason, only a hacker
would use 0.  In that discussion, however, it became clear that
several people for whom I have great respect, and who are definitly
software engineers and not hackers (Paul Lucas and Pete Becker come to
mind) preferred 0 to NULL, even while recognizing that the technical
imperative was no longer valid.  As a result, I am forced to consider
this a question of style.  (But I still think my style is better:-).)
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article CoM@netcom.com, sbarton@netcom.com (Sharon Barton) writes:
>Can anyone tell me why Thomas Plum and Donald Saks recommend using
>0 to initialize pointers instead of NULL in their C++ Programming
>Guidelines book?  This isn't consistent with ANSI C.  Isn't C++
>based on ANSI C?

I think it was because when that book was written, many compilers defined
NULL the way C compilers often does it: ((void*) 0). This can give you a
LOT of problems, so in C++ this was changed. NULL can in C++ be defined as
0, OL, or something else, but NOT as ((void*) 0). The recommendation was
important then and is probably still important for some, but will hopefully
not be important in the future.

I use 0.

Mats Henricson
Ellemtel Telecom Systems Labs
Stockholm
Sweden

James Kanze (kanze@us-es.sel.de) wrote:
: In article <sbartonCJwGnu.CoM@netcom.com> sbarton@netcom.com (Sharon
: Barton) writes:

: |> Can anyone tell me why Thomas Plum and Donald Saks recommend using
: |> 0 to initialize pointers instead of NULL in their C++ Programming
: |> Guidelines book?  This isn't consistent with ANSI C.  Isn't C++
: |> based on ANSI C?

: Here we go again:-(.

: Historically, a number of early C++ compilers (well, at least one)
: were really just front-ends for the C compiler.  In addition, since
: the commercial market was not worth the effort, the simple solution of
: just enrobing the standard C header files in extern "C" { ... } was
: adapted.

: In C, NULL may be legally defined as '(void*)0', and some systems
: actually do this.  This works well in C, since a void* can be assigned
: to any type of pointer.  On the other hand, C++ does not allow an
: implicit cast *from* void*, and this lead to the fact that you could
: not assign NULL to a pointer (nor compare a pointer to NULL, nor...).

: Today, there is a significant commercial market for C++; if the header
: files for C++ define NULL as '(void*)0', then a complaint to your
: vendor is in order.  In fact, I know of no current implementation
: where this is the case.  So there is no *technical* reason not to use
: NULL.

How about...

template<class T>
class Null {
  public:
    static T* Ptr()   { return (T*)0; }
};

//...

main()
{
    double* dp;
    //...

    dp = Null<double>::Ptr();
    //...
    if (dp == Null<double>::Ptr())
    //...
}


I never try this because it's just too horible for a hacker but
a soft eng like you may love it :)

LD


: The question of style remains.  I have many years of C experience, and
: in all of the companies, the house style was to use NULL.  I find that
: information is missing when 0 is used; the type system is being
: abused.  In fact, until the last big discussion of this on the net, I
: was convinced that without the obslete technical reason, only a hacker
: would use 0.  In that discussion, however, it became clear that
: several people for whom I have great respect, and who are definitly
: software engineers and not hackers (Paul Lucas and Pete Becker come to
: mind) preferred 0 to NULL, even while recognizing that the technical
: imperative was no longer valid.  As a result, I am forced to consider
: this a question of style.  (But I still think my style is better:-).)
: --
: James Kanze                             email: kanze@us-es.sel.de
: GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
: Conseils en informatique industrielle --
:                    -- Beratung in industrieller Datenverarbeitung

Can anyone tell me why Thomas Plum and Donald Saks recommend using
0 to initialize pointers instead of NULL in their C++ Programming
Guidelines book?  This isn't consistent with ANSI C.  Isn't C++
based on ANSI C?

Thanks in advance,
Sharon Casaletto
scasalet@abbotthpd.com