In article <37B96E10.60F8@wanadoo.fr>,
  Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
>
> James.Kanze@dresdner-bank.com wrote:

> > For the compiler, whether you use 0 or NULL makes no difference;
> > using NULL does *not* guarantee a null pointer when passed to a
> > varargs function.

> NULL shall never be used for vararg arguments in C or C++.

> (void*)0 shall only be used to pass a void*.

> When using %p in printf, if I am not mistaken, the value
> should first be converted to void*.

Correct on all three counts.  So what to say about the early UNIX man
pages for execl, which gave as an example:

    int execl (Path, Argument0 [, Argument1, ...], 0)

These were later "corrected" to:

    int execl (Path, Argument0 [, Argument1, ...], NULL)

Neither of which are correct, of course.  (BTW: the first version
managed to hang around long enough ... that I could cut and paste from a
Window on an AIX when writing this:-).)

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 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              ]

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37B8C28F.6A4BF1E0@acm.org...
> > > void f(long);
> > > void f(char *);
> > > f(3);          // not ambiguous
> > > f(0);          // ambiguous!
> > > f(NULL);  // also ambiguous!
> > I don't understand your point. Of course f(NULL) is ambiguous here. NULL
> > is #defined as 0, which is an int, and calling f with an int 0 is
> > ambiguous. So don't do that.
>
> The point is "IT SHOULDN'T BE AMBIGUOUS!"
>

MAYBE, MAYBE NOT. BUT SHOUTING ISN'T PERSUADING. And giving examples of
ambiguity without stating why they are problems also isn't persuasive.
Stating the reasons that you believe the language should be changed can
be persuasive, if you give good, convincing reasons.

--
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              ]

In article <7peav9$31i9$1@news.hal-pc.org>,
Greg Brewer <nospam.gregb@hal-pc.org> wrote:
>  Capital i and lowercase L are
>indistinguishable in the in the windows dialog font.  I was trying to
>replace a variable name and the new variable had a "lI" sequence in it.  It
>just didn't look right.  Doesn't look right in this message either.  Of
>cource, you may be using another font.

As a general rule, these look indistinguishable in *any* san-serif font.
[Though there may be some exceptions].
That is why I use a serif font for most purposes.


[ 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              ]

Greg Brewer wrote:
>
> blargg <postmast.root.admi.gov@iname.com> wrote
> > Lots of people think that using int is *non-portable* (silly, eh?),
> > but using long or short *is* portable, because they imagine that it
> > has guarantees on bit size.
>
> Lots of people may have been transitioning from 16 bit windows to 32
> bit windows.  During that transition, int had 2 different sizes but
> long or short remain the same.

Indeed.  Short is guaranteed to have at least 16 bits, and long is
guaranteed at least 32 bits.  These are not "imagined" guarantees;
they are quite real.

But beware, when transitioning from Win32 to Win64, long will *not*
have two sizes (it will still be 32 bits wide)...

-- 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              ]

James.Kanze@dresdner-bank.com wrote:
>
> In article <7p79mi$17sr$1@news.hal-pc.org>,
>   "Greg Brewer" <nospam.gregb@hal-pc.org> wrote:
>
> > You seem to very carefully have stepped around the one case that
> > causes trouble.
> > That being,
> >
> > void f(long);
> > void f(char *);
> >
> > f(3);          // not ambiguous
> > f(0);          // ambiguous!
> > f(NULL);  // also ambiguous!
>
> That's not really a problem either, since it generates a compiler
> error.  The case which causes trouble today is:
>
>     void f( int ) ;
>     void f( char* ) ;
>
>     f( NULL ) ;     //  not ambiguous, calls f( int )!
>
> There are two solutions to this problem:
>
> 1. avoid NULL, because it is misleading in this case, or
> 2. use reasonable names for the functions, so that you don't have
>    functions overloaded to take int or char*.

Yeah, so don't do stupid things like:

    cout << NULL;

-- 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              ]

Greg Brewer wrote:
> These days when I'm working with shorts, the compilers are way too
> quick to convert to an int then complain that I might lose
> significant digits when I try to store the results in a short.
> Something like,
>    short i = 5;  // okay
>    i += 8;  // warning will robinson....
> I know, I know
>    i += (short)8
> works fine.  But I would personally prefer
>    i += 8S

Except that 8S and 85 look too much alike.  But 8s would be okay.
(The same way that 8l looks to much like 81, but 8L doesn't.)

-- 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              ]

David R Tribble <david@tribble.com> wrote in message
news:37B9EC74.F76899B6@tribble.com...
> Except that 8S and 85 look too much alike.  But 8s would be okay.
> (The same way that 8l looks to much like 81, but 8L doesn't.)

That reminds me of a very difficult problem someone was having that I looked
out.  The printout said a variable was undefined but it was clearly defined.
Turned out the printer's capital ohs and zeros were indistinguishable.  I
ran into a similar problem yesterday.  Capital i and lowercase L are
indistinguishable in the in the windows dialog font.  I was trying to
replace a variable name and the new variable had a "lI" sequence in it.  It
just didn't look right.  Doesn't look right in this message either.  Of
cource, you may be using another font.

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              ]

blargg <postmast.root.admi.gov@iname.com> wrote in message
news:user-1308991426410001@as1-dialup-03.io.com...
> Lots of people think that using int is *non-portable* (silly, eh?), but
> using long or short *is* portable, because they imagine that it has
> guarantees on bit size.

Lots of people may have been transitioning from 16 bit windows to 32 bit
windows.  During that transition, int had 2 different sizes but long or
short remain the same.

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              ]

Pete Becker <petebecker@acm.org> wrote in message
news:37B47533.F668011B@acm.org...
> Christian Bau wrote:
> >
> > In article <37B2B51E.DC612862@acm.org>, Pete Becker <petebecker@acm.org>
wrote:
> > The weird thing is that you can pass whatever constant
> > number you want to pass, except zero.
>
> I don't know what this means.
>
> void f(int);
> void f(void *);
> f(0); // legal, calls f(int)

True enough.

> The "problem" with actual ambiguities when calling with 0 (e.g. a
> function overloaded for long and for a pointer) is really the same
> "problem" as this:
>
> void f(short);
> void f(long);
>
> f(3); // ambiguous

Also true.  You seem to very carefully have stepped around the one case that
causes trouble.
That being,

void f(long);
void f(char *);

f(3);          // not ambiguous
f(0);          // ambiguous!
f(NULL);  // also ambiguous!

> In order to call a function correclty you must know the types of the
> arguments that it takes. If you don't pay attention to argument types
> you may be surprised, but that's your own fault.

My example is what Christian was referring to.

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              ]

Greg Brewer wrote:
>
> blargg <postmast.root.admi.gov@iname.com> wrote in message
> news:user-1308991426410001@as1-dialup-03.io.com...
> > Lots of people think that using int is *non-portable* (silly, eh?), but
> > using long or short *is* portable, because they imagine that it has
> > guarantees on bit size.
>
> Lots of people may have been transitioning from 16 bit windows to 32 bit
> windows.  During that transition, int had 2 different sizes but long or
> short remain the same.

No, because all of those differences are hidden by macros in MS's
headers. <g> This silliness long predates Win32. It's more of a UNIXism.

--
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              ]

In article <user-1308991426410001@as1-dialup-03.io.com>,
  postmast.root.admi.gov@iname.com (blargg) wrote:

> I use an identifier in my programs that represents the NULL pointer. I
use
> 0 when I want the integer zero. I don't see why one would want to use
the
> integer zero when they really mean "the singular pointer of the
> appropriate type that points to no object".

There are two separate issues.

For the compiler, whether you use 0 or NULL makes no difference; using
NULL does *not* guarantee a null pointer when passed to a varargs
function.  The actual type of NULL is (typically) int.

For the reader, I find it preferable to consistantly give him as much
information as possible.  Thus, the terminator of a C style string is
*always* '\0' (not 0 or NULL), a real integral constant is always 0
(including when the integer is actually a 'signed char'), and a null
pointer is always NULL.  I know enough C/C++ however to be well aware of
the fact that these distinctions are, for all practical purposes, just
comments as far as the language is concerned.  (In many implementations
of C, all three really are exactly the same: a constant of type int and
value 0.  In C++, '\0' has type char, whereas the other two will
typically have type int.)

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 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              ]

Pete Becker <petebecker@acm.org> wrote in message
news:37B2B51E.DC612862@acm.org...
> Greg Brewer wrote:
> >
> > No, this is not something I would remember.  I personally tend use 0L
alot
> > simply because I have adopted a policy of not including files if I don't
> > need them and so I don't depend on NULL being defined.
> >
>
> That explains the ambiguities you complained about: 0L is of type long,
> so if you use it as an argument to a function that's overloaded for int
> and some pointer it's ambiguous. Why not use a plain 0, like everyone
> else does?

I got in the habit of using #L in the 16 bit days.  I would frequently get
the wrong answer because intermediate answers of calculations with literals
where 16 bit ints and the answer would exceed the range of a 16 bit integer
before conversion of 32 bit integer.

I've wondered if 0L is part of the standard or just a common extension.
These days when I'm working with shorts, the compilers are way too quick to
convert to an int then complain that I might lose significant digits when I
try to store the results in a short.  Something like,
   short i = 5;  // okay
   i += 8;  // warning will robinson....
I know, I know
   i += (short)8
works fine.  But I would personally prefer
   i += 8S
---
[ 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              ]

In article <37B2E224.43C7@wanadoo.fr>,
  Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
>
> Pete Becker wrote:

> > That explains the ambiguities you complained about: 0L is of type
long,
> > so if you use it as an argument to a function that's overloaded for
int
> > and some pointer it's ambiguous. Why not use a plain 0, like
everyone
> > else does?

> No one is complaining about the fact that NULL does not
> prefer the function taking an int.

No, but at least some people are complaining about the fact that NULL
does prefer the function taking an int.  This is, IMHO, a salient
argument against using NULL today: f( NULL ) will call f( int ), and not
f( void* ).

I prefer NULL anyway.  I don't have any functions named f.  My function
names reflect the semantics of the function, and in practice, I've not
run into cases where a function taking a pointer and a function taking
an int would have the same name anyway.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orientie objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh|ttenweg 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              ]

Greg Brewer wrote:
>
> Also true.  You seem to very carefully have stepped around the one case that
> causes trouble.
> That being,
>
> void f(long);
> void f(char *);
>
> f(3);          // not ambiguous
> f(0);          // ambiguous!
> f(NULL);  // also ambiguous!
>
> > In order to call a function correclty you must know the types of the
> > arguments that it takes. If you don't pay attention to argument types
> > you may be surprised, but that's your own fault.
>
> My example is what Christian was referring to.
>

I don't understand your point. Of course f(NULL) is ambiguous here. NULL
is #defined as 0, which is an int, and calling f with an int 0 is
ambiguous. So don't do that.

--
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              ]

In article <7p79mi$17sr$1@news.hal-pc.org>,
  "Greg Brewer" <nospam.gregb@hal-pc.org> wrote:

> You seem to very carefully have stepped around the one case that
> causes trouble.
> That being,
>
> void f(long);
> void f(char *);
>
> f(3);          // not ambiguous
> f(0);          // ambiguous!
> f(NULL);  // also ambiguous!

That's not really a problem either, since it generates a compiler
error.  The case which causes trouble today is:

    void f( int ) ;
    void f( char* ) ;

    f( NULL ) ;     //  not ambiguous, calls f( int )!

There are two solutions to this problem:

1. avoid NULL, because it is misleading in this case, or
2. use reasonable names for the functions, so that you don't have
   functions overloaded to take int or char*.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 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              ]

James.Kanze@dresdner-bank.com wrote:

> For the compiler, whether you use 0 or NULL makes no difference; using
> NULL does *not* guarantee a null pointer when passed to a varargs
> function.

NULL shall never be used for vararg arguments in C or C++.

(void*)0 shall only be used to pass a void*.

When using %p in printf, if I am not mistaken, the value
should first be converted to void*.

--

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              ]

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37B2B51E.DC612862@acm.org...
> > Greg Brewer wrote:
> > >
> > > No, this is not something I would remember.  I personally tend use 0L
> alot
> > > simply because I have adopted a policy of not including files if I don't
> > > need them and so I don't depend on NULL being defined.
> > >
> >
> > That explains the ambiguities you complained about: 0L is of type long,
> > so if you use it as an argument to a function that's overloaded for int
> > and some pointer it's ambiguous. Why not use a plain 0, like everyone
> > else does?
>
> I got in the habit of using #L in the 16 bit days.  I would frequently get
> the wrong answer because intermediate answers of calculations with literals
> where 16 bit ints and the answer would exceed the range of a 16 bit integer
> before conversion of 32 bit integer.
>
> I've wondered if 0L is part of the standard or just a common extension.

It's in section 6.4.4.1 of the C9X standard; I'm pretty sure it was in
C89 as well. It not only designates 'long integer'; on integer
constants, but also 'long double' on floating point constants; There's
also U for unsigned, and F for float. Any of these may be lower case.

> These days when I'm working with shorts, the compilers are way too quick to
> convert to an int then complain that I might lose significant digits when I
> try to store the results in a short.  Something like,
>    short i = 5;  // okay
>    i += 8;  // warning will robinson....
> I know, I know
>    i += (short)8
> works fine.  But I would personally prefer
>    i += 8S

That sounds like a nice idea, but it's not currently in the standard.
'F' provides a precedent for shortening the size, so I can't see why
not.















.
---
[ 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              ]

Pete Becker <petebecker@acm.org> wrote in message
news:37B8C28F.6A4BF1E0@acm.org...
> > void f(long);
> > void f(char *);
> > f(3);          // not ambiguous
> > f(0);          // ambiguous!
> > f(NULL);  // also ambiguous!
> I don't understand your point. Of course f(NULL) is ambiguous here. NULL
> is #defined as 0, which is an int, and calling f with an int 0 is
> ambiguous. So don't do that.

The point is "IT SHOULDN'T BE AMBIGUOUS!"




[ 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              ]

In article <37B2B51E.DC612862@acm.org>, Pete Becker <petebecker@acm.org> wrote:

> Greg Brewer wrote:
> >
> > No, this is not something I would remember.  I personally tend use 0L alot
> > simply because I have adopted a policy of not including files if I don't
> > need them and so I don't depend on NULL being defined.
> >
>
> That explains the ambiguities you complained about: 0L is of type long,
> so if you use it as an argument to a function that's overloaded for int
> and some pointer it's ambiguous. Why not use a plain 0, like everyone
> else does?

That would be the same problem if a function is overloaded for long and
some pointer. The weird thing is that you can pass whatever constant
number you want to pass, except zero.
---
[ 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              ]

In article <37B2B51E.DC612862@acm.org>, Pete Becker <petebecker@acm.org> wrote:

> Greg Brewer wrote:
> >
> > No, this is not something I would remember.  I personally tend use 0L alot
> > simply because I have adopted a policy of not including files if I don't
> > need them and so I don't depend on NULL being defined.
> >
>
> That explains the ambiguities you complained about: 0L is of type long,
> so if you use it as an argument to a function that's overloaded for int
> and some pointer it's ambiguous. Why not use a plain 0, like everyone
> else does?

Lots of people think that using int is *non-portable* (silly, eh?), but
using long or short *is* portable, because they imagine that it has
guarantees on bit size. They would rather hide bugs in their code (using
0L in a vararg func that takes a pointer type, with the assumption that
all pointer types have the same representation as a long, *and* that the
NULL pointer is represented by the all-zero bit battern). Or perhaps they
think that using 0L insures that all bits are zero for the NULL pointer (I
won't even try to explain this type of confusion :-)

I use an identifier in my programs that represents the NULL pointer. I use
0 when I want the integer zero. I don't see why one would want to use the
integer zero when they really mean "the singular pointer of the
appropriate type that points to no object".


[ 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              ]

Christian Bau wrote:
>
> In article <37B2B51E.DC612862@acm.org>, Pete Becker <petebecker@acm.org> wrote:
>
> > Greg Brewer wrote:
> > >
> > > No, this is not something I would remember.  I personally tend use 0L alot
> > > simply because I have adopted a policy of not including files if I don't
> > > need them and so I don't depend on NULL being defined.
> > >
> >
> > That explains the ambiguities you complained about: 0L is of type long,
> > so if you use it as an argument to a function that's overloaded for int
> > and some pointer it's ambiguous. Why not use a plain 0, like everyone
> > else does?
>
> That would be the same problem if a function is overloaded for long and
> some pointer.

The point of that statement was that adopting idiosyncratic coding
conventions produces code that other will find hard to understand. His
initial complaint was of an ambiguity in calling a function that was
overloaded for an int and a pointer. With 0 that isn't ambiguous. With
0L it is. By talking about "the 0 problem" he misled readers.

> The weird thing is that you can pass whatever constant
> number you want to pass, except zero.

I don't know what this means.

void f(int);
void f(void *);
f(0); // legal, calls f(int)

The "problem" with actual ambiguities when calling with 0 (e.g. a
function overloaded for long and for a pointer) is really the same
"problem" as this:

void f(short);
void f(long);

f(3); // ambiguous

In order to call a function correclty you must know the types of the
arguments that it takes. If you don't pay attention to argument types
you may be surprised, but that's your own fault.

--
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              ]

Pete Becker wrote:

> That explains the ambiguities you complained about: 0L is of type long,
> so if you use it as an argument to a function that's overloaded for int
> and some pointer it's ambiguous. Why not use a plain 0, like everyone
> else does?

No one is complaining about the fact that NULL does not
prefer the function taking an int.

--

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              ]

> IOWs, most code as there has been long standing advice from eminent C++
> gurus to simply use 0 and forgo the problems of NULL being
> inconveniently defined (remember that for many years we were likely to
> be using plain C header files)

No, this is not something I would remember.  I personally tend use 0L alot
simply because I have adopted a policy of not including files if I don't
need them and so I don't depend on NULL being defined.




[ 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              ]

Greg Brewer wrote:
>
> No, this is not something I would remember.  I personally tend use 0L alot
> simply because I have adopted a policy of not including files if I don't
> need them and so I don't depend on NULL being defined.
>

That explains the ambiguities you complained about: 0L is of type long,
so if you use it as an argument to a function that's overloaded for int
and some pointer it's ambiguous. Why not use a plain 0, like everyone
else does?

--
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              ]