"dani_carles@hotmail.com" schrieb:
> Could somebody confirm that this code is standard ?
>=20
> template< class T> class MyTemplateClass
> {
> public:
> MyTemplateClass( const T &Data) {}
> ~MyTemplateClass() {}
> };
> int main()
> {
> MyTemplateClass<int *> MyVar( /*static_cast<int *>*/ (0));
> return 0;
> }

as far as i can see a dereferenciation is missing, isn't it?  like this:
MyTemplateClass<int *> MyVar( *(static_cast<int *>(0)) );

otherwise you try to assign a pointer to int to a ref to int which is
not ok.

regards

 robert


--=20
Robert Klemme
Software Engineer
-------------------------------------------------------------
myview technologies GmbH & Co. KG
Riemekestra=DFe 160 ~ D-33106 Paderborn ~ Germany
E-Mail: mailto:robert.klemme@myview.de
Telefon: +49/5251/69090-321 ~ Fax: +49/5251/69090-399
-------------------------------------------------------------

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

Robert Klemme <robert.klemme@myview.de> wrote in message
news:3AE690C3.EFEFE5C@myview.de...

"dani_carles@hotmail.com" schrieb:
>> Could somebody confirm that this code is standard ?
>>
>> template< class T> class MyTemplateClass
>> {
>> public:
>> MyTemplateClass( const T &Data) {}
>> ~MyTemplateClass() {}
>> };
>> int main()
>> {
>> MyTemplateClass<int *> MyVar( /*static_cast<int *>*/ (0));
>> return 0;
>> }

> as far as i can see a dereferenciation is missing, isn't it?  like this:
> MyTemplateClass<int *> MyVar( *(static_cast<int *>(0)) );
No, it's not. Because the call is to the specialization
'MyTemplateClass<int*>::MyTemplateClass(int*const&)' of the constructor of
the class template 'MyTemplateClass'.

> otherwise you try to assign a pointer to int to a ref to int which is
> not ok.
No, what's happening is that the constructor parameter of type 'int*const&'
is being copy initialized with a null pointer constant (a null pointer value
of type 'int*' if the static_cast is uncommented). As the ititializer
expression is an r-value not of a class type, a temporary of type
'int*const' is created and the parameter is bound to it. See the last bullet
of 8.5.3/5.


Sincerely,

Andrei Iltchenko.



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

Andrei Iltchenko schrieb:
>=20
> Robert Klemme <robert.klemme@myview.de> wrote in message
> news:3AE690C3.EFEFE5C@myview.de...
>=20
> "dani_carles@hotmail.com" schrieb:
> >> Could somebody confirm that this code is standard ?
> >>
> >> template< class T> class MyTemplateClass
> >> {
> >> public:
> >> MyTemplateClass( const T &Data) {}
> >> ~MyTemplateClass() {}
> >> };
> >> int main()
> >> {
> >> MyTemplateClass<int *> MyVar( /*static_cast<int *>*/ (0));
> >> return 0;
> >> }
>=20
> > as far as i can see a dereferenciation is missing, isn't it?  like th=
is:
> > MyTemplateClass<int *> MyVar( *(static_cast<int *>(0)) );
> No, it's not. Because the call is to the specialization
> 'MyTemplateClass<int*>::MyTemplateClass(int*const&)' of the constructor=
 of
> the class template 'MyTemplateClass'.

yes, of course!  you are right - i overlooked this.  thank you!

 robert


--=20
Robert Klemme
Software Engineer
-------------------------------------------------------------
myview technologies GmbH & Co. KG
Riemekestra=DFe 160 ~ D-33106 Paderborn ~ Germany
E-Mail: mailto:robert.klemme@myview.de
Telefon: +49/5251/69090-321 ~ Fax: +49/5251/69090-399
-------------------------------------------------------------

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

The following code fails to compile with Windriver's Diab C++ compiler which
claims to be ANSI/ISO Standard compliant. The static_cast below needs to be
uncommented for the code to compile. I compiled it with MS Visual C++ 6.0, gcc
and Comeau online with no problems. Windriver's support team seem to believe
their behaviour is standard. I personally don't think so and would like to reply
to them with a relevant quote from the Standard. I think 4.10.1 might be
relevant, but there might be a better place to quote from:

"A null pointer constant is an integral constant expression (5.19) rvalue of
integer type that evaluates to
zero. A null pointer constant can be converted to a pointer type; the result is
the null pointer value of that
type and is distinguishable from every other value of pointer to object or
pointer to function type. Two null
pointer values of the same type shall compare equal. The conversion of a null
pointer constant to a pointer
to cv-qualified type is a single conversion, and not the sequence of a pointer
conversion followed by a qual-ification
conversion (4.4)."

Could somebody confirm that this code is standard ?

template< class T> class MyTemplateClass
{
public:
MyTemplateClass( const T &Data) {}
~MyTemplateClass() {}
};
int main()
{
MyTemplateClass<int *> MyVar( /*static_cast<int *>*/ (0));
return 0;
}

Thanks in advance,

--- Dani

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

dani_carles@hotmail.com <Dani.Carles@rutgers.edu> wrote in message
news:BZcF6.3077$QV4.256281@www.newsranger.com...
> The following code fails to compile with Windriver's Diab C++ compiler
which
> claims to be ANSI/ISO Standard compliant. The static_cast below needs to
be
> uncommented for the code to compile. I compiled it with MS Visual C++ 6.0,
gcc
> and Comeau online with no problems. Windriver's support team seem to
believe
> their behaviour is standard. I personally don't think so and would like to
reply
> to them with a relevant quote from the Standard. I think 4.10.1 might be
> relevant, but there might be a better place to quote from:
>
> "A null pointer constant is an integral constant expression (5.19) rvalue
of
> integer type that evaluates to
> zero. A null pointer constant can be converted to a pointer type; the
result is
> the null pointer value of that
> type and is distinguishable from every other value of pointer to object or
> pointer to function type. Two null
> pointer values of the same type shall compare equal. The conversion of a
null
> pointer constant to a pointer
> to cv-qualified type is a single conversion, and not the sequence of a
pointer
> conversion followed by a qual-ification
> conversion (4.4)."
>
> Could somebody confirm that this code is standard ?
>
> template< class T> class MyTemplateClass
> {
> public:
> MyTemplateClass( const T &Data) {}
> ~MyTemplateClass() {}
> };
> int main()
> {
> MyTemplateClass<int *> MyVar( /*static_cast<int *>*/ (0));
> return 0;
> }

A Standard C++ conforming implementation shall compile the above piece of
code regardless of the presence of the static_cast in the argument
expression, as both the following declarations are well-formed:
int   *const tmp = 0;
int   *const tmp = static_cast<int*>(0);
and the initialization of the parameter 'Data' of the copy constructor of
the class template specialization 'MyTemplateClass<int*>', which has a
reference type, is done by binding it to a temporary of type 'int*const'
that is in turn initialized as though by one of the above two declarations.
See 8.5.3/5 of the Standard.


Cheers,

Andrei Iltchenko.


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

Jamshid Afshar <jamshid@io.com> writes:

|>  In article <345B0DE9.D77E59F4@student.uq.edu.au>,
|>  Ted Clancy  <s341282@student.uq.edu.au> wrote:
|>  >Paul D. DeRocco wrote:
|>  >> About the only advantage is that in some circumstances you can
|>  >> leave off a cast. For instance, if you've got a function with a
|>  >> ... parameter, and you want to pass a null pointer to it, but a
|>  >> pointer is longer than an int in the particular implementation
|>  >> in question, then you have to cast NULL at least to (void*) to
|>  >> make it long enough. [...]
|>  >
|>  >Using __null still makes it safe to leave off the cast. If another
|>  >function with a different pointer type suddenly turns up, the compiler
|>  >can complain about an ambiguity, and then you can add the cast.
|>
|>  A __null keyword does not offer any advantages over NULL when calling
|>  a variadic function, unless you're sure that function will interpret
|>  the argument as a void* and not another kind of pointer.  Standard C++
|>  (and Standard C) do not guarantee that all pointer types are the same
|>  size or have the same representation -- the types int*, void*,
|>  void (*)(), and void (Foo::*)() may all have a different size or their
|>  bit representation may be different.

In the initial proposal, passing a __null to a variadic function
resulted in an error unless it was casted to the desired type.
Precisely because passing NULL to a variadic function is such a common
error.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
        I'm looking for a job -- Je recherche du travail
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <345B0DE9.D77E59F4@student.uq.edu.au>,
Ted Clancy  <s341282@student.uq.edu.au> wrote:
>Paul D. DeRocco wrote:
>> About the only advantage is that in some circumstances you can
>> leave off a cast. For instance, if you've got a function with a
>> ... parameter, and you want to pass a null pointer to it, but a
>> pointer is longer than an int in the particular implementation
>> in question, then you have to cast NULL at least to (void*) to
>> make it long enough. [...]
>
>Using __null still makes it safe to leave off the cast. If another
>function with a different pointer type suddenly turns up, the compiler
>can complain about an ambiguity, and then you can add the cast.

A __null keyword does not offer any advantages over NULL when calling
a variadic function, unless you're sure that function will interpret
the argument as a void* and not another kind of pointer.  Standard C++
(and Standard C) do not guarantee that all pointer types are the same
size or have the same representation -- the types int*, void*,
void (*)(), and void (Foo::*)() may all have a different size or their
bit representation may be different.

Jamshid Afshar
jamshid@io.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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Roger Onslow wrote:
>
> Nice theory - but it could be a BIG disaster in practice.
>
> What happens to this sort of code..
>
> void *p = NULL;
> ...
> if (!p) {
>     ...
> }
>
> if NULL is __null and __null may not cast to 0, then you cannot use a
> pointer like this in an 'if' to test a pointer.
>
> This sort of code is very common and will suddenly not work anymore.
>
> Roger

Sorry, but p is not of type typeof(__null), but of type
pointer to void (void*). What happens in the code above,
is that __null is converted to a null pointer of type
void*, and operator! is applied to *this* pointer (i.e. p).
The type of p is not changed by assigning __null to it!

So the only code that could break is:

if(!NULL)
  ...

Now, have you ever seen this written? :-)
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Paul D. DeRocco wrote:
>
> Skip Sailors wrote:
> >
> > Is there a problem with using 0 for the null pointer; the un-referenceable
> > address?  What do you get by using NULL that you don't get with 0?
>
> About the only advantage is that in some circumstances you can
> leave off a cast. For instance, if you've got a function with a
> ... parameter, and you want to pass a null pointer to it, but a
> pointer is longer than an int in the particular implementation
> in question, then you have to cast NULL at least to (void*) to
> make it long enough.
>
> One might hope that __null would solve some overloading
> problems, but in the general case, in order to invoke a function
> that takes either an int or a pointer parameter, you'd still
> have to cast __null to the correct pointer type, in case there
> was yet another function that took a different pointer type.

Using __null still makes it safe to leave off the cast. If another
function with a different pointer type suddenly turns up, the compiler
can complain about an ambiguity, and then you can add the cast.

Ambiguity is okay, because the compiler can complain. What we want to
avoid is the compiler favouring 'int', 'long', or 'void*' without
telling us.

--
Visit the USS-Unique! http://student.uq.edu.au/~s341282/UQ-Trek/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Skip Sailors wrote:
>
> Is there a problem with using 0 for the null pointer; the un-referenceable
> address?  What do you get by using NULL that you don't get with 0?

About the only advantage is that in some circumstances you can
leave off a cast. For instance, if you've got a function with a
... parameter, and you want to pass a null pointer to it, but a
pointer is longer than an int in the particular implementation
in question, then you have to cast NULL at least to (void*) to
make it long enough.

One might hope that __null would solve some overloading
problems, but in the general case, in order to invoke a function
that takes either an int or a pointer parameter, you'd still
have to cast __null to the correct pointer type, in case there
was yet another function that took a different pointer type.

--

Ciao,
Paul
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

If I remember correctly, Bjarne makes a pretty good argument that there
shouldn't be NULL or __null or anything like that, when 0 (zero) is there.
Zero is what we try to make NULL mean in the context of addresses.

Is there a problem with using 0 for the null pointer; the un-referenceable
address?  What do you get by using NULL that you don't get with 0?

Michael Quinlan wrote in message <3450ee39.35183160@news.primenet.com>...
nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:

>
>David R Tribble <dtribble@technologist.com> writes:
>
>[ A proposal for a reserved identifier __null with very similar properties
>to the macro NULL. ]
>...
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:

>Fergus Henderson wrote:
> >
> > >Why couldn't I initialize a reference to a pointer with
> > >__null?
> >
> > Because `__null' is not an lvalue.
> > (Initializing a const reference with `__null' should be allowed, though.)
>
>Is this post-CD2?

No.  It is pre-CD1.  I think it is from the ARM or before.
See 8.5.3 [dcl.init.ref].

--
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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Barry Margolin <barmar@bbnplanet.com> writes:

> In article <62vr0t$nlr$3@pumba.class.udg.mx>,
> Roger Onslow <No_Spam@hotmail.com> wrote:
> >What happens to this sort of code..
> >
> >void *p = NULL;
> >...
> >if (!p) {
> >    ...
> >}
> >
> >if NULL is __null and __null may not cast to 0, then you cannot use a
> >pointer like this in an 'if' to test a pointer.
>
> There should probably be a specific exception to allow casting to bool, but
> not other integral types.

And there is a standard convertion to bool but no others
integral types.

But you may implicitly convert a bool to any other integral type,
so you can convert a pointer to an integer (0 or 1) without any
explicit cast:

bool b = p;
int i = b; // i has the value int (p != 0)

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:

>David R Tribble wrote:
>>
>>  (7) The '__null' identifier may be passed as an argument to a
>>  function.  In C++, it shall not be passed to a function or a
>>  constructor as an argument of reference type.
>
>Why not? Why couldn't I initialize a reference to a pointer with
>__null?

Because `__null' is not an lvalue.
(Initializing a const reference with `__null' should be allowed, though.)

> void foo(int *p);
> void bar(int &*p);
>
> foo(__null); // if this is legal,
> bar(__null); //  then this should be legal

Consider what would happen if bar() were defined like this:

 void bar(int *&p) {
  static int x;
  p = &x;   // oops, now __null == &x ?
 }

--
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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Nice theory - but it could be a BIG disaster in practice.

What happens to this sort of code..

void *p = NULL;
...
if (!p) {
    ...
}

if NULL is __null and __null may not cast to 0, then you cannot use a
pointer like this in an 'if' to test a pointer.

This sort of code is very common and will suddenly not work anymore.

Roger

David R Tribble wrote in message
<2.2.32.19971024011329.002e1d18@central.beasys.com>...
[snip]
> (16) The '__null' identifier may be cast to an integral type, but the
> resulting integer value is implementation-defined.  In particular,
> the resulting integer value might or might not compare equal to
> integer zero.  The integer type must be wide enough to contain all of
> the bits of a null pointer to void; casting to smaller types may
> result in the truncation of high-order bits and is implementation-
> defined behavior.  (The 'size_t' and 'ptrdiff_t' types might or might
> not be wide enough.  Types 'unsigned long int' and 'unsigned long
> long int' probably have sufficient width and are the safest integral
> types to use.)
[snip]
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Roger Onslow <No_Spam@hotmail.com> writes:

> David R Tribble wrote in message
> <2.2.32.19971024011329.002e1d18@central.beasys.com>...
> [snip]
> > (16) The '__null' identifier may be cast to an integral type, but the
> > resulting integer value is implementation-defined.  In particular,
> > the resulting integer value might or might not compare equal to
> > integer zero.

> Nice theory - but it could be a BIG disaster in practice.
>
> What happens to this sort of code..
>
> void *p = NULL;
> ...
> if (!p) {
>     ...
> }
>
> if NULL is __null and __null may not cast to 0, then you cannot use a
> pointer like this in an 'if' to test a pointer.

Disastrous theory, but it __null would work nicely in
practice (at least from this point of view).

operator! takes a bool in C++. A pointer converts to true
iff it's non-null, so !p == true when p is null.

Works the same way for 'if (p)'.

There is no (and never was) any convertion to integer in
either case.

What isn't clear in the proposal is the type of __null.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Fergus Henderson wrote:
>
> "Paul D. DeRocco" <pderocco@ix.netcom.com> writes:
>
> >David R Tribble wrote:
> >>
> >>  (7) The '__null' identifier may be passed as an argument to a
> >>  function.  In C++, it shall not be passed to a function or a
> >>  constructor as an argument of reference type.
> >
> >Why not? Why couldn't I initialize a reference to a pointer with
> >__null?
>
> Because `__null' is not an lvalue.
> (Initializing a const reference with `__null' should be allowed, though.)
>
> >       void foo(int *p);
> >       void bar(int &*p);
> >
> >       foo(__null);    // if this is legal,
> >       bar(__null);    //  then this should be legal
>
> Consider what would happen if bar() were defined like this:
>
>         void bar(int *&p) {
>                 static int x;
>                 p = &x;                 // oops, now __null == &x ?
>         }

Is this post-CD2? I understand the logic behind it, but when I
peruse CD2, it appears that the compiler should create a
temporary pointer variable initialized with zero, and pass a
reference to it into the function, regardless of whether the
parameter is const or not.

--

Ciao,
Paul
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <62vr0t$nlr$3@pumba.class.udg.mx>,
Roger Onslow <No_Spam@hotmail.com> wrote:
>What happens to this sort of code..
>
>void *p = NULL;
>...
>if (!p) {
>    ...
>}
>
>if NULL is __null and __null may not cast to 0, then you cannot use a
>pointer like this in an 'if' to test a pointer.

There should probably be a specific exception to allow casting to bool, but
not other integral types.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
Support the anti-spam movement; see <http://www.cauce.org/>
Please don't send technical questions directly to me, post them to newsgroups.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <2.2.32.19971024011329.002e1d18@central.beasys.com> David R Tribble <david.tribble@central.beasys.com> writes:
<
< ======================= Important note ===============================
<  This proposal applies to both the C and the C++ languages.  There is
<  a large overlap for both languages; where a specific constraint or
<  example applies only to one of the languages, it is stated as such,
<  i.e., the item contains a clause like "in C" or "for C++".  Items
<  without such a clause should be considered to apply to both
<  languages.
< <elided...>
<
<  PROPOSAL
<
<  A reserved identifier, '__null', is to be added to the language to
<  serve as a null pointer constant.

...which reminds me that Scott Meyers' "Effective C++" 2nd ed. has
a NULL class as an application of member templates.  I am not sure
how useful this thing is since in all honesty I have never run into
a problem due to the lack of a NULL in C/C++ and the whole issue
seems academic to me but maybe I was lucky.  Anyway, here is the class:

const class {   // Anonymous
public:
    template<class T>
    operator T*() const {
 return 0;
    }
    template<class C, class T>
    operator T C::*() const {
 return 0;
    }
private:
    void operator&() const; // Don't define
} NULL;

This is quite contrived but it resolves the overloading problem
(check Item 25 in the book if it's not clear why it works).
--
Jan Bielawski                        )\._.,--....,'``.
Molecular Simulations, Inc.         /,   _.. \   _\  ;`._ ,.
San Diego, CA                   fL `._.-(,_..'--(,_..'`-.;.'
jpb@msi.com  http://www.msi.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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

[cross-posted to comp.std.c]

nmm1@cus.cam.ac.uk (Nick Maclaren) asked [on comp.std.c]:
> What you haven't explained is why this is useful, compared with using the
> macro NULL.  In particular:
>    1) What can you do with it that you can't with NULL?
>    2) What checking does it give you that you don't get with NULL?

Please refer to the full document, particularly the EXAMPLES section, which
is at <http://www.flash.net/~dtribble/text/c9xnull.txt>.  (If you don't
have a web browser, I can email you a copy.)  It should answer your questions.

Here's a brief summary:

 1)  The __null identifier is not the same as NULL.  NULL can be '0', '0L',
     or '(void*)0', which of course isn't completely portable.  The
     situation is even worse in C++, where NULL must be '0' or '0L' - it's
     not even a pointer type.  __null is one thing and one thing only -
     a null pointer constant.

     True, you can't use __null for anything more that what you can use
     NULL for.  But you can use NULL for things that you can't use __null
     for, since NULL is less type safe (see the next answer).

 2)  The following statements are legal in C++, and in implementations of
     C that #define NULL to be '0' or '0L':

        int    i;
        char   ch;
        char * cp;
        float  f;

        i = NULL;
        ch = NULL;
        *cp = NULL;
        f = NULL;
        memset(cp, NULL, i);
        cp = NULL + 0;
        cp = NULL - NULL * NULL;
        f =  NULL - NULL * NULL;
        cp = cp + NULL;
        ch = cp[NULL];

     These are all illegal when __null is used instead.  NULL was not
     meant to be a synonym for zero, but unfortunately it can be.

Also bear in mind that my proposal is designed to replace NULL with:
    #define NULL  __null
All conforming programs that currently use NULL correctly will remain
unaffected.  Programs that don't, however, will now have compile-time
errors (which is the right thing to do).

-- David R. Tribble, david.tribble@central.beasys.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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:

>
>David R Tribble <dtribble@technologist.com> writes:
>
>[ A proposal for a reserved identifier __null with very similar =
properties
>to the macro NULL. ]
>
>What you haven't explained is why this is useful, compared with using =
the
>macro NULL.  In particular:
>
>    1) What can you do with it that you can't with NULL?
>
>    2) What checking does it give you that you don't get with NULL?

In C++ (but not C, of course) if you have two overloaded functions where
one function takes an int as a parameter and the other function takes a
pointer as a parameter, calling the function with NULL as the parameter
currently calls the wrong function.

example:

    void func(int);
    void func(int *);

    func(NULL)  // Calls func(int) instead of func(int *)

I too would like to know what the advantages of the proposal are for the =
C
language.
--
Michael Quinlan
mikeq@prodigy.net
http://www.primenet.com/~mikeq
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

David R Tribble wrote:
>
>  (7) The '__null' identifier may be passed as an argument to a
>  function.  In C++, it shall not be passed to a function or a
>  constructor as an argument of reference type.

Why not? Why couldn't I initialize a reference to a pointer with
__null?

 void foo(int *p);
 void bar(int &*p);

 foo(__null); // if this is legal,
 bar(__null); //  then this should be legal

--

Ciao,
Paul
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

NOTE:
 This posting is rather long, so please don't quote it in its entirety
 when posting responses or comments about it.

 This version of the proposal has been edited to make it shorter; only
 the interesting portions have been included.  Sections that have been
 removed are marked as '<elided...>'.  This document is still quite
 long, though.  The full text can be found at:
 <http://www.flash.net/~dtribble/text/c9xnull.txt>.  If you want a
 copy by email, I can send you one.

DISCLAIMER:
 Since we have been told many times now that it's too late to submit
 new proposals to the ANSI/ISO committees for both C and C++, I'm not
 making the futile effort of formally making this proposal to them.
 Instead, I am posting this 'suggestion' to the newsgroups in the hope
 that it will: 1) stimulate discussion about the semantic 'holes' in the
 language(s), especially in regards to type safety, and 2) be seriously
 considered as a viable enhancement by real compiler vendors.  Perhaps
 if enough people think it's a good idea and enough vendors actually
 implement it, it may be considered for adoption in 5 to 8 years when
 the next revision(s) to the language(s) will be made.

======================= Important note ===============================
 This proposal applies to both the C and the C++ languages.  There is
 a large overlap for both languages; where a specific constraint or
 example applies only to one of the languages, it is stated as such,
 i.e., the item contains a clause like "in C" or "for C++".  Items
 without such a clause should be considered to apply to both
 languages.
<elided...>

 PROPOSAL

 A reserved identifier, '__null', is to be added to the language to
 serve as a null pointer constant.

 The '__null' name is a predefined identifier with a type of 'pointer'
 and a value of 'null pointer'.  The type of '__null' is assignment-
 compatible with all pointer types.  Its value compares equal to all
 null pointer expressions regardless of their type, and unequal to any
 (non-null) pointer to a valid object or function.

 A new definition of the 'NULL' macro (in the <stddef.h> header file)
 is also suggested (see the COMPATIBILITY section below).

 PROBLEM STATEMENT

 C and C++ currently lack an explicit null pointer constant keyword or
 identifier.  The integer constant zero is deemed a special case that
 can be used for such a value.  This practice, however, is the source
 of some semantic (type checking) problems.
<elided...>

 CONSTRAINTS

 The following paragraphs describe the constraints on the '__null'
 identifier.  (See the EXAMPLES section below for illustrations of
 these constraints.)

 (1) No header file needs to be #included to make the '__null'
 identifier visible in a translation unit; the identifier is
 predefined (i.e., it is built into the language).

 (2) The name '__null' is a reserved identifier.  It shall not be used
 as the name of any library or user-defined object or function, nor as
 the name of any struct or union tag or member, nor as an enumeration
 tag or constant, nor as a typedef name, nor as a statement label.
 Whether or not '__null' may be used as the name of a preprocessor
 macro is implementation-defined.  (Note, however, that since it
 begins with two underscores it is reserved for use by the language or
 implementation.)

 (3) The '__null' identifier may be used as an operand in equality
 expressions (involving the '==' and '!=' operators) for comparison to
 pointer expressions.  In C++, it may be compared to pointer to member
 expressions.

 (4) The '__null' identifier shall not be used as an operand in a
 relational expression (involving the '<', '<=', '>', or '>='
 operators).  In C++, '__null' may be used as an argument to these
 operators provided that they have been overloaded and take a pointer
 argument.

 (5) The '__null' identifier may be used as an an r-value in
 assignment expressions.  It is assignment-compatible with every
 pointer type.  It may be used as the value (right) operand of the
 simple assignment operator ('='), but shall not be the operand of any
 of the compound assignment operators ('*=', '/=', '%=', '+=', '-=',
 '>>=', '<<=', '&=', '^=', and '|=').  In C++, '__null' may be used as
 an argument to these operators provided that they have been
 overloaded and take a pointer argument.

 In C++, '__null' is also compatible with every pointer to member
 type.

 (6) The '__null' identifier is a constant expression, and may be used
 as an initialization-expression to initialize a variable of pointer
 type.  In C++, it may also be used to initialize a variable of a
 pointer to member type.  In C++, '__null' shall not be used to
 initialize a reference variable.

 (7) The '__null' identifier may be passed as an argument to a
 function.  In C++, it shall not be passed to a function or a
 constructor as an argument of reference type.

 (8) The '__null' identifier has a type, which is an incomplete
 pointer type.  However, it is compatible with all pointer types.  In
 C++, it is also compatible with all pointer to member types.  (It
 does not have type 'pointer to void'.  Its specific type depends on
 the context in which it is used.)

 (9) The '__null' identifier is type-compatible with pointer types
 having any combination of 'const' or 'volatile' qualifiers.

 (10) Casting '__null' to a particular pointer type yields a null
 pointer of that type, which compares equal to any other null pointer
 value of that type.  Whether or not the bitwise representation of a
 null pointer value of one type is the same as that of null pointers
 of other types is implementation-defined.  The conversion of '__null'
 to a cv-qualified pointer type is a single conversion operation, and
 not a sequence of a pointer conversion followed by a qualification
 conversion.  In C++, '__null' may be cast to any pointer to member
 type, yielding a null pointer to member value of that type, which
 compares equal to any other null pointer to member of the same type,
 and unequal to any pointer to member of the same type that was not
 derived from a null pointer value.

 (11) The '__null' identifier is not an l-value.  It shall not be the
 target operand of an assignment or increment operator.

 (12) The '__null' identifier does not designate an addressable
 object, and thus it does not have an address.  The unary '&' operator
 shall not be applied to it.

 (13) The '__null' value does not point to a valid object and thus
 shall not be dereferenced (by the unary '*' operator or the '[]'
 operator).  It shall not be used as an operand in a pointer
 arithmetic expression (involving the binary '+' or '-' operators).
 In C++, it may be passed as an argument to the binary '+' or '-'
 operators provided that they have been overloaded and take a pointer
 argument.

 The '__null' identifier shall not be dereferenced as a function
 designator in order to call a function.  In C++, it does not
 designate any member of any struct or class object and shall not be
 dereferenced as a pointer to member.

 (14) The '__null' identifier has a size.  For purposes where the
 complete type is not needed (such as when it is used as an argument
 of the 'sizeof' operator), the size of '__null' is the same as the
 size of type 'pointer to void'.

 (15) The '__null' identifier is not type-compatible with non-pointer
 types.  In particular, it is not type-compatible with integral types.

 (16) The '__null' identifier may be cast to an integral type, but the
 resulting integer value is implementation-defined.  In particular,
 the resulting integer value might or might not compare equal to
 integer zero.  The integer type must be wide enough to contain all of
 the bits of a null pointer to void; casting to smaller types may
 result in the truncation of high-order bits and is implementation-
 defined behavior.  (The 'size_t' and 'ptrdiff_t' types might or might
 not be wide enough.  Types 'unsigned long int' and 'unsigned long
 long int' probably have sufficient width and are the safest integral
 types to use.)

 (17) Casting an integer value, which was the result of previously
 casting '__null' to an integer type, to type 'pointer to void' yields
 a null pointer value that compares equal to '__null' (provided that
 the integer type is wide enough).  Casting the integer value to any
 other pointer type yields a value that is implementation-defined and
 which might or might not compare equal to '__null'.

 EXAMPLES
<elided...>

 COMPATIBILITY CONSIDERATIONS

 In the interests of providing backward compatibility to existing
 code, the definition of the 'NULL' macro can be changed in the
 standard header files (specifically, <stddef.h>) to:

    #define NULL  __null

<elided...>
 This change has no detrimental effects on conforming programs that
 use 'NULL' correctly.

 ISSUES
<elided...>

 LIBRARY CONSIDERATIONS
<elided...>

 COMMENTS

 The new '__null' identifier is meant to replace the use of '0' as a
 null pointer constant.  In all situations involving pointer
 expressions, the use of '0' can be replaced with '__null' without
 affecting the semantics.  '__null' cannot be used as a replacement
 for '0' in other situations, however, particularly within arithmetic
 expressions.

 Code that currently uses 'NULL' correctly will not be affected by
 this proposal.

 I do not advocate changing the existing semantics of using integer
 constant zero as a null pointer constant in this proposal.

 FUTURE CONSIDERATIONS

 With the introduction of the '__null' identifier, the practice of
 using the constant '0' (integer zero) as a null pointer constant
 could be deprecated.  However, it cannot simply be removed from the
 language today because so much existing code relies on it.
<elided...>

 CONCLUSION
<elided...>

 REFERENCES

 ANSI/ISO 9899-1990 Standard for Programming Languages - C, the
 following sections:
   6.2.2.3  Pointers
   6.3.2.2  Function calls
   6.3.3.2  Address and indirection operators
   6.3.4    Cast operators
   6.3.6    Additive operators
   6.3.8    Relational operators
   6.3.9    Equality operators
   6.3.16   Assignment operators
   6.3.16.1 Simple assignment
   6.3.16.2 Compound assignment
   6.4      Constant expressions
   7.1.6    Common definitions <stddef.h>

 ISO/IEC JTC1/SC22 Programming Language C++, committee draft 2 (CD
 14882), Dec 1996, the following sections:
   4.10  Pointer conversions
   4.11  Pointer to member conversions

====================== End of Proposal =====================
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]