"David R Tribble" <david@tribble.com> wrote in message
news:3999BCE5.FF645D@tribble.com...
> Niels Dekker wrote:
> >> Well, I just hope that C++ will provide me a more convenient way to
> >> distinguish between an integral zero expression and a null pointer...
>
> Valentin Bonnard wrote:
> > We already have a reserved spelling for that, it's NULL (not a
> > keyword, but very close). So just write NULL and use a good compiler.
>
> The standard definition of NULL isn't good enough.
>
>     // Valid standard C++ code
>     int   i = NULL;
>     char  c = NULL;
>     i += NULL;
>     memset(buf, NULL, len);
>     if (p - NULL > q) ...
>
> A "good" compiler would define NULL to be something semantically
> better than 0, such as '__null__'.  But such a compiler is
> technically not conforming.


What you really need is a typed NULL constant. The problem is that you can't
define NULL to be of any one given pointer type because the various pointer
types are not convertible to each other. So here's a class that can do that.

Scott Meyers posted this in a thread entitled "Who's pathetic, me or C++
compilers?" where he was asking about a bunch of errors that resulted from
him not having a default constructor.

class _null_impl_class_reallylongbizarreclassnametoavoidcollissionsoruse{
/* needs a typename to have a default constructor */
public:
    _null_impl_class_reallylongbizarreclassnametoavoidcollissionsoruse(){}
    /*needs a default constructor unless a defect
    report is issued fixing this*/

    template<class T> operator T*() const{ return 0; }
    /*convertible to any type of pointer*/

    template<class C, class T> operator T C::*() const { return 0; }
    /*or to any type of member pointer*/

private:
    void operator&() const{} /*address can't be taken*/
}

const _null_impl_class_reallylongbizarreclassnametoavoidcollissionsoruse
NULL;


Scott Meyers' code was somewhat different (eliminating the class name and
combining all of the above into one definition) but he posted it showing a
list of compiler errors that stemmed from the lack of a default constructor
and a VC++ error that seemed to have different problems.
http://x63.deja.com/threadmsg_ct.xp?AN=644660779.1&mhitnum=0&CONTEXT=9670465
84.770244614

You can see Meyers' code and errors by visiting the link above to the
message on deja.


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

Niels Dekker wrote:
>> Well, I just hope that C++ will provide me a more convenient way to
>> distinguish between an integral zero expression and a null pointer...

Valentin Bonnard wrote:
> We already have a reserved spelling for that, it's NULL (not a
> keyword, but very close). So just write NULL and use a good compiler.

The standard definition of NULL isn't good enough.

    // Valid standard C++ code
    int   i = NULL;
    char  c = NULL;
    i += NULL;
    memset(buf, NULL, len);
    if (p - NULL > q) ...

A "good" compiler would define NULL to be something semantically
better than 0, such as '__null__'.  But such a compiler is
technically not conforming.

--
David R. Tribble, mailto:david@tribble.com, http://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              ]

Trevor L. Jackson, III wrote:

> Niels Dekker wrote:
>
> > Valentin Bonnard wrote:
> > >
> > > Niels Dekker wrote:
> > >
> > > > But if this is not according to the Standard, I would like to have a
> > > > static member called zero() added to numeric_limits,
> > >
> > > Seriously, would you use it ?
> >
> > I think such a zero() function would fit in nicely with the min(), the
> > max(), and the other members of numeric_limits.
> >
> > But you asked me:
> > >
> > > Seriously, would you use it ?
> >
> > Hmmm... So you think std::numeric_limits<char>::zero() is a little bit
> > verbose?  But then again, so is std::numeric_limits<char>::min(), and
> > aren't you using that one as well?
>
> min() is a limit, while zero() is not -- it is not descriptive of the
> platform.  Zero fits nicely into numeric_constants<> along with pi(), e(),
> various logarithms, and minus zero.
>
> I'd rather see numeric_limits add:
>
> bool has_minus_zero;        // sign+magnitude ints as well as iec559 floats
> T minus_zero();

It isn't a limit either. What about -T() ?

What's the point of sign+magnitude ints -0 (if they exist at all) ?

> and some bit position descriptors to compose/decompose numbers in a portable
> way:
>
> int sign_bit;
> int mant_bit;
> int exp_bit;

Why not use frexp ?

--

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              ]

Valentin Bonnard wrote:

> Trevor L. Jackson, III wrote:
>
> > Niels Dekker wrote:
> >
> > > Valentin Bonnard wrote:
> > > >
> > > > Niels Dekker wrote:
> > > >
> > > > > But if this is not according to the Standard, I would like to have a
> > > > > static member called zero() added to numeric_limits,
> > > >
> > > > Seriously, would you use it ?
> > >
> > > I think such a zero() function would fit in nicely with the min(), the
> > > max(), and the other members of numeric_limits.
> > >
> > > But you asked me:
> > > >
> > > > Seriously, would you use it ?
> > >
> > > Hmmm... So you think std::numeric_limits<char>::zero() is a little bit
> > > verbose?  But then again, so is std::numeric_limits<char>::min(), and
> > > aren't you using that one as well?
> >
> > min() is a limit, while zero() is not -- it is not descriptive of the
> > platform.  Zero fits nicely into numeric_constants<> along with pi(), e(),
> > various logarithms, and minus zero.
> >
> > I'd rather see numeric_limits add:
> >
> > bool has_minus_zero;        // sign+magnitude ints as well as iec559 floats
> > T minus_zero();
>
> It isn't a limit either. What about -T() ?

The presence of absence of minus zero is certainly descriptive of the platform, so
has_minus_zero is useful.  The reason one would want
numeric_limits<>::minus_zero() is that composing a minus zero in a portable way is
problematic.  The literal -0 is usually not reduced to the appropriate bit
pattern, but taken as a constant expression and reduced by the compiler to the
literal zero.

>
>
> What's the point of sign+magnitude ints -0 (if they exist at all) ?
>
> > and some bit position descriptors to compose/decompose numbers in a portable
> > way:
> >
> > int sign_bit;
> > int mant_bit;
> > int exp_bit;
>
> Why not use frexp ?

I'd much prefer to use frexp and ldexp.  However, they are a fairly restrictive
interface to the underlying numeric properties.  They make the fundamental
assumption that all floating point values are numbers.  What's the exponent of
zero, infinity or NaN?

Also there are (in my insufficiently broad experience) many implementations that
do not handle denorms well.  I suppose handling denorms well is a performance
penalty that is unacceptable for most applications.

Lastly, iec559 NaNs offer a diagnostic capability that is not widely supported,
but quite valuable when used with care.  The only mechanism we have for composing
diagnostic NaNs is some kind of bit twiddling.

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

Valentin Bonnard wrote:
>
> Niels Dekker wrote:
>
> > But if this is not according to the Standard, I would like to have a
> > static member called zero() added to numeric_limits,
>
> Seriously, would you use it ?

I think such a zero() function would fit in nicely with the min(), the
max(), and the other members of numeric_limits.

But you asked me:
>
> Seriously, would you use it ?

Hmmm... So you think std::numeric_limits<char>::zero() is a little bit
verbose?  But then again, so is std::numeric_limits<char>::min(), and
aren't you using that one as well?


> Seriously, would you use it ?

Well, I just hope that C++ will provide me a more convenient way to
distinguish between an integral zero expression and a null pointer...

Did I answer your question?  Maybe I should become a politician  :-)

Take care,

Niels Dekker
ndekker "at" nki "dot" nl

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

Niels Dekker wrote:
>
> Valentin Bonnard wrote:
> >
> > Niels Dekker wrote:
> >
> > > But if this is not according to the Standard, I would like to have a
> > > static member called zero() added to numeric_limits,
> >
> > Seriously, would you use it ?
>
> I think such a zero() function would fit in nicely with the min(), the
> max(), and the other members of numeric_limits.

For zero() we already have T(0) and T().

Granted, there is no garanty that any of them will work for UDT, but
there is no garanty either that numeric_limits will be specialized
for UDT. And T(0) or T() are sooo easier to type.

> > Seriously, would you use it ?
>
> Well, I just hope that C++ will provide me a more convenient way to
> distinguish between an integral zero expression and a null pointer...

We already have a reserved spelling for that, it's NULL (not a keyword,
but very close). So just write NULL and use a good compiler.

> Did I answer your question?

Yes, it is clear that you don't really want to use it.

> Maybe I should become a politician  :-)

Maybe I should become a journalist.

--

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              ]

Valentin Bonnard <Bonnard.V@wanadoo.fr> writes:

|>  Niels Dekker wrote:

|>  > But if this is not according to the Standard, I would like to have =
a
|>  > static member called zero() added to numeric_limits,=20

|>  Seriously, would you use it ?

Not systematically:-).

In practice, however, I find numeric_limits invaluable when writing
template code for numeric types.  In this context, I could very well
imagine using it to get a zero value of the correct type.  Which is less
verbose: numeric_limits<T>.zero(), or static_cast<T>( 0 )?

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

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

Niels Dekker wrote:

> Valentin Bonnard wrote:
> >
> > Niels Dekker wrote:
> >
> > > But if this is not according to the Standard, I would like to have a
> > > static member called zero() added to numeric_limits,
> >
> > Seriously, would you use it ?
>
> I think such a zero() function would fit in nicely with the min(), the
> max(), and the other members of numeric_limits.
>
> But you asked me:
> >
> > Seriously, would you use it ?
>
> Hmmm... So you think std::numeric_limits<char>::zero() is a little bit
> verbose?  But then again, so is std::numeric_limits<char>::min(), and
> aren't you using that one as well?

min() is a limit, while zero() is not -- it is not descriptive of the
platform.  Zero fits nicely into numeric_constants<> along with pi(), e(),
various logarithms, and minus zero.

I'd rather see numeric_limits add:

bool has_minus_zero;        // sign+magnitude ints as well as iec559 floats
T minus_zero();

and some bit position descriptors to compose/decompose numbers in a portable
way:

int sign_bit;
int mant_bit;
int exp_bit;



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

cesar_quiroz@my-deja.com writes:

>In article <8l9lvi$qon$1@news.netmar.com>,
>  wmm@fastdial.net wrote:
>> In a previous article,  Niels Dekker  <ndekker@REMOVETHISnki.nl>
>writes:
>> >
>> >I'm still hoping that the T() construction will bring me this
>> >"zero-value that is not a null-pointer". ...
>> There was existing legacy C code that defined NULL to be OL or OUL.
>> ...
>
>Given that C++ was meant to be largely compatible with C, and that ISO
>C (6.2.2.3) already spoke of random integer constants that evaluate to
>0, C++ had little choice.

Well, C++ already disallowed `(void *)0', which C89 allows, even
though `(void *)0' would have made a better null pointer than `0'
in C++, since it works better in the presence of overloading.

So clearly backwards compatibility was not the main issue.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

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

Niels Dekker wrote:

> But if this is not according to the Standard, I would like to have a
> static member called zero() added to numeric_limits,

Seriously, would you use it ?

--

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              ]

In a previous article,  Niels Dekker  <ndekker@REMOVETHISnki.nl> writes:
>
>I'm still hoping that the T() construction will bring me this
>"zero-value that is not a null-pointer". For the time being the current
>version of MSVC++ still rejects (ptr == char()).

I wouldn't count on it.  I can't predict what the full Committee
will do (that's why we have meetings), but the limited discussion
so far indicates unanimous support for the idea that the Standard
either already does or should treat "char()" as an integral
constant expression.

>So I'm also interested in the more fundamental question:
>What is the ratio behind allowing the use of constants like 0UL, '\0',
>false, (2*1*0), and char() as a null pointer? To me the null pointer
>seems such a magical and exceptional thing that C++ might have been more
>strict: why not rejecting the use of any integer constant other than the
>literal 0 as a null pointer?

There was existing legacy C code that defined NULL to be OL or OUL.
The reason for that was to handle implementations where a pointer
is the same size as a long and longer than an int; that way if you
passed NULL to a non-prototyped function, you'd get the correct
number of bits pushed on the stack.

Given that, why shouldn't 0x0 or 0x0UL be permitted?  And so on --
anyplace you drew a line would be arbitrary.  Since there was already
need for a definition for integral constant expression, it was just
natural to piggyback onto it for the definition of null pointer
constant rather than creating an arbitrary definition out of whole
cloth.

-- William M. Miller


     -----  Posted via NewsOne.Net: Free Usenet News via the Web  -----
     -----  http://newsone.net/ --  Discussions on every subject. -----
   NewsOne.Net prohibits users from posting spam.  If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse@newsone.net

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

Niels Dekker wrote:
....
> What is the ratio behind allowing the use of constants like 0UL, '\0',
> false, (2*1*0), and char() as a null pointer? To me the null pointer
> seems such a magical and exceptional thing that C++ might have been more
> strict: why not rejecting the use of any integer constant other than the
> literal 0 as a null pointer?

I'd guess that it was an issue of backwards compatibility with C. Of
course, now that C++ has been around long enough, it's become a matter
of backwards compatibility with itself.

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

MSVC++ is not the only compiler that cannot convert each possible constant
integral zero expression to a pointer. I was happy to find Borland reject
the following misleading (if not buggy!) line of code:
  bool *pb = false;  // BC++ 5.5: Cannot convert 'bool' to 'bool *'
Unfortunately I understand that this line of code is legal C++.

So I was wondering:
> What is the ratio behind allowing the use of constants like 0UL, '\0',
> false, (2*1*0), and char() as a null pointer?

William M. Miller replied:
>
> There was existing legacy C code that defined NULL to be OL or OUL.
> The reason for that was to handle implementations where a pointer
> is the same size as a long and longer than an int; that way if you
> passed NULL to a non-prototyped function, you'd get the correct
> number of bits pushed on the stack.

Okay, this explains why any literal integral zero is allowed as pointer: for
the sake of C-compatibility. I'm surprised about this, because on the other
hand C++ rejects the use of ((void*)0) as a generic pointer, even though
this is common practice in C.
Also I think there is not enough reason for C++ to allow non-C contructs
like char() and false as a pointer.

James Kuyper wrote:
>
> Of course, now that C++ has been around long enough, it's become a matter
> of backwards compatibility with itself.

Well, I don't think there's a lot of C++ code out here that uses anything
like (2*1*0), char() and false as a pointer. Unless it is a bug!
To help us C++ programmers in our efforts to write bug-free code, it would
be a good thing if the Committee would call the use of such expressions as a
pointer "deprecated".


Niels Dekker
ndekker "at" nki "dot" nl

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

Niels Dekker wrote:
>
> MSVC++ is not the only compiler that cannot convert each possible constant
> integral zero expression to a pointer. I was happy to find Borland reject
> the following misleading (if not buggy!) line of code:
>   bool *pb = false;  // BC++ 5.5: Cannot convert 'bool' to 'bool *'
> Unfortunately I understand that this line of code is legal C++.
>
> So I was wondering:
> > What is the ratio behind allowing the use of constants like 0UL, '\0',
> > false, (2*1*0), and char() as a null pointer?
>
> William M. Miller replied:
> >
> > There was existing legacy C code that defined NULL to be OL or OUL.
> > The reason for that was to handle implementations where a pointer
> > is the same size as a long and longer than an int; that way if you
> > passed NULL to a non-prototyped function, you'd get the correct
> > number of bits pushed on the stack.
>
> Okay, this explains why any literal integral zero is allowed as pointer: for
> the sake of C-compatibility. I'm surprised about this, because on the other
> hand C++ rejects the use of ((void*)0) as a generic pointer, even though
> this is common practice in C.
> Also I think there is not enough reason for C++ to allow non-C contructs
> like char() and false as a pointer.
>
> James Kuyper wrote:
> >
> > Of course, now that C++ has been around long enough, it's become a matter
> > of backwards compatibility with itself.
>
> Well, I don't think there's a lot of C++ code out here that uses anything
> like (2*1*0), char() and false as a pointer. Unless it is a bug!
> To help us C++ programmers in our efforts to write bug-free code, it would
> be a good thing if the Committee would call the use of such expressions as a
> pointer "deprecated".

On the other hand, I wouldn't be surprised to see 0x0, 0U, 0L, or 0UL in
use for that purpose.

---
[ 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 <8l9lvi$qon$1@news.netmar.com>,
  wmm@fastdial.net wrote:
> In a previous article,  Niels Dekker  <ndekker@REMOVETHISnki.nl>
writes:
> >
> >I'm still hoping that the T() construction will bring me this
> >"zero-value that is not a null-pointer". ...
> There was existing legacy C code that defined NULL to be OL or OUL.
> ...

Given that C++ was meant to be largely compatible with C, and that ISO
C (6.2.2.3) already spoke of random integer constants that evaluate to
0, C++ had little choice.  The golden opportunity was lost in C89 (or,
in fairness, in the previous years, when C implementations
proliferated).

K&R1 App. A 7.14 says at the end: "... However, it is guaranteed that
assignment of the constant 0 to a pointer will produce a null pointer
distinguishable from a pointer to any object", without being detained
too long on whether that constant 0 was any of those covered by
A.2.4.1, or just plain one zero character.  It *was* still possible to
standardize on a unique spelling of the name of the null pointer
(namely, the token consisting exactly of '0' in the source character
set) and be compatible with K&R1.  Past the point where the C standard
accomodated other spellings, the loss was irreversible.

> Given that, why shouldn't 0x0 or 0x0UL be permitted?  And so on --
> anyplace you drew a line would be arbitrary.

But we need arbitrary lines!  No one expects these to yield null
pointers:

char *nUlL = 4*atan(1.0) - 2*acos( 0.0 ); /* yeah, right */
extern int i;
char *NUll = i - i;

We do have an arbitrary line; pre-C89 it could have been instead: "The
token 0 is a guaranteed name of the NULL pointer; any other constant
integer that evaluates to zero in a pointer context is left for the
implementation to define". That is (still in C):

char *np = 0; /* guaranteed to be a NULL pointer */
char *cp = 0x0; /* good candidate for pointing to address zero, but
                 * unportable any way, because it could be the null
                 * pointer in some perverse implementation :-)
                 */

Even in implementations where "address zero" is ambiguous or undefined,
you would get the benefit of stricter checking (at least you would be
warned if you manufactured an unexpected zero, say from nested macro
expansions).

Under such rule, 0L is *not* a portable representation of the NULL
pointer in standard C, but a given implementation may define it so for
their purposes (while still also being forced to understand plain 0 as
a NULL pointer, of course).  However, no implementation would be forced
to interpret as NULL any other zero, constant or not, that ended up
assigned to a pointer -- it would just be free to document when other
zeroes spell a NULL pointer.

The net cost would be that us programmers
would have had to be very careful to not spell NULL with 00, 0x0, 0-
0, '\0' or any other constants that amount to zero; the net benefit,
that the lucky among us would have had a name for address zero.

In the balance, I feel that the alternative world with a unique
guaranteed spelling for zero might have been preferable by an epsilon.
It is not a big deal either way, just annoying :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

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

Biju Thomas wrote:
>
> The above code [comparing pointer to "char()"]
> should be ill-formed.

William M. Miller, wmm@fastdial.net wrote:
>
> I'll check with the Committee to see if there's any
> controversy about it or interest in treating it as an issue.

Thanks very much.

So I was lucky to have the obsolete MSVC++ 4.2 rejecting my (ptr ==
'\0') expression. With a Standard-conforming compiler I would not have
found this bug! But of course I don't want to stick with MSVC++ 4.2
forever! So to avoid such bugs in the future, I should limit the use of
zero-literals of any integral type in my C++ code. And find myself a
better way to say "zero"!

I'm still hoping that the T() construction will bring me this
"zero-value that is not a null-pointer". For the time being the current
version of MSVC++ still rejects (ptr == char()).

But if this is not according to the Standard, I would like to have a
static member called zero() added to numeric_limits, which would
typically be implemented as follows:
  template<typename T>
  const T numeric_limits<T>::zero(void) throw()
  {
    return T();
  }

I'm pretty sure that with this addition to numeric_limits the following
would be ill-formed:

  void f(const char ptr[])
  {
    if( ptr == numeric_limits<char>::zero() )
    {
      // From here I was assuming that ptr points to a zero character!
      // Oops  :-(  !!!
    }
  }

(That's ill-formed, isn't it?)
So this zero() would offer a more robust way to use an integral zero
that is not a null-pointer!


Still I understand that both of the following bugs are legal C++,
unfortunately:
  bool b;
  bool * pb;
  pb = false;  // Bug: should be: *pb = false;

  int i;
  int* pi = &i;
  pi = 2*1*0;  // Bug, should be: *pi = 2*1*0;

So I'm also interested in the more fundamental question:
What is the ratio behind allowing the use of constants like 0UL, '\0',
false, (2*1*0), and char() as a null pointer? To me the null pointer
seems such a magical and exceptional thing that C++ might have been more
strict: why not rejecting the use of any integer constant other than the
literal 0 as a null pointer?


Thanks again!

Niels Dekker
ndekker "at" nki "dot" nl

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