On Wed, 13 Mar 2002 19:03:01 GMT, "Garry Lancaster"
<glancaster@ntlworld.com> wrote:

[...]

>We also have bool, a type with two possible
>values and that is instantiable. It's arguable
>whether null_type is closest to void or to bool.
>(Or maybe it is closest to void* ?)
>I don't think we can resolve this one by analogy.
>

It's not a matter of analogy. Let me be clearer: incompleteness is not
a necessity; we could allow null_type be instantiatable but that's
*superfluous* (for void, on the contrary, it makes *no sense*)

>> I'd like such a type to be not instantiatable.
>
>But why? What harm does instantiating it do?

It doesn't hurt, as I said above. :)

>> After thinking a bit about the problem (what? do you post here without
>> first thinking about your questions? :)), does it make sense to
>> overload on null_type?
>>
>> Have you any example in which it would be useful?
>
>Sure. Two actually.
>
>1. A smart pointer that doesn't deal with raw pointers,
>but still wants to deal with null.

[code snipped]

>
>smart_ptr sp;
>....
>sp = NULL;

Yes, it's nice. Could be done with a reset() member function, but it's
nice.

>if( sp == NULL )

Similar to the above. Nice, even though feasible with an operator
!().... [ Ok, don't immolate me, but I'd prefer something like

 if (! ! sp)
 ....

:)
]

>{
>....
>
>2. A stream-like class that needs to be tested for
>good/bad.
>
[...]

>mystream ms;
>int i;
>ms >> i;
>if( ms == NULL )
>{

In this case I'd largely prefer an operator!().


>> And what about
>> template specialization?
>
>You brought that one up, so really you should
>provide the example. I just agreed with you ;-)
>
>It might be used as a typelist terminator, but there
>are lots of types that could do that. It seems to me
>that a lot of the interesting things you can do with
>templates weren't "designed in" - they just emerged
>afterwards after people played with them.

Yes, that's why I introduced the idea. Your statement made me
immediately think to Erwin Unruh's prime numbers and all the
remarkable things that followed that discovery


[link snipped]
>
>(This link didn't work for me - and yes I did paste
>it back together - but I have seen recent discussions
>on the subject.)
>

Try with
http://groups.google.com/groups?hl=it&ie=ISO-8859-1&oe=ISO-8859-1&threadm=9u0u7q%24uic%241%40nntp1.ba.best.com
(paste it all, watching out 'false' new-lines)


Thanks for your replies,
Genny.

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

"Garry Lancaster" <glancaster@ntlworld.com> wrote in message news:<PM4j8.26137$yc2.2845361@news2-win.server.ntlworld.com>...

> I did give other reasons for wanting a complete
> type earlier in the discussion and I also think
> - why make it more complicated than it need be?

null_type (as we friendly call it ;)) is a special case. We already
have
void which has the peculiarity of being an "empty type": a type with
no values. Now we want a type which can have *one* possible value
(i.e. 0p). I'd like such a type to be not instantiatable.

After thinking a bit about the problem (what? do you post here without
first thinking about your questions? :)), does it make sense to
overload on null_type?

Have you any example in which it would be useful? And what about
template specialization?


P.S.:

a) there is another thing on which probably we haven't understood
each other: I think of null_type as a primitive type, what you don't
judging from your operator ==() examples.

b)  [I took a look at comp.std.c++ archive: there are many recent
threads about this issue. See for instance
http://groups.google.com/groupshl=it&threadm=32DAD544.7983%40student.uq.edu.au&rnum=2&prev=/groups%3Fhl%3Dit%26q%3Dc%252B%252B%2Bstd%253A%253Anull%2Boverload]


Genny.

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

Garry Lancaster:
> > I did give other reasons for wanting a complete
> > type earlier in the discussion and I also think
> > - why make it more complicated than it need be?

Gennaro Prota:
> null_type (as we friendly call it ;)) is a special case. We already
> have
> void which has the peculiarity of being an "empty type": a type with
> no values. Now we want a type which can have *one* possible value
> (i.e. 0p).

We also have bool, a type with two possible
values and that is instantiable. It's arguable
whether null_type is closest to void or to bool.
(Or maybe it is closest to void* ?)
I don't think we can resolve this one by analogy.

> I'd like such a type to be not instantiatable.

But why? What harm does instantiating it do?

> After thinking a bit about the problem (what? do you post here without
> first thinking about your questions? :)), does it make sense to
> overload on null_type?
>
> Have you any example in which it would be useful?

Sure. Two actually.

1. A smart pointer that doesn't deal with raw pointers,
but still wants to deal with null.

class smart_ptr
{
public:
    // ...
    smart_ptr& operator=(null_type);
    friend bool operator==(const smart_ptr& lhs, null_type);
    // ...
};

permits

smart_ptr sp;
....
sp = NULL;
if( sp == NULL )
{
....

2. A stream-like class that needs to be tested for
good/bad.

class mystream
{
public:
    // ...
    friend bool operator==(const smart_ptr& lhs, null_type);
    // ...
};

permits

mystream ms;
int i;
ms >> i;
if( ms == NULL )
{
....

and avoids the usual hacky bool or void* implicit
conversion.

> And what about
> template specialization?

You brought that one up, so really you should
provide the example. I just agreed with you ;-)

It might be used as a typelist terminator, but there
are lots of types that could do that. It seems to me
that a lot of the interesting things you can do with
templates weren't "designed in" - they just emerged
afterwards after people played with them. Even
if there is no killer example, unless there is a
particular reason to ban specializing on this type,
the presumption should be that it behaves just
like any other type in this respect.

> P.S.:
>
> a) there is another thing on which probably we haven't understood
> each other: I think of null_type as a primitive type, what you don't
> judging from your operator ==() examples.

I think it is correct that it should be a primitive type.

> b)  [I took a look at comp.std.c++ archive: there are many recent
> threads about this issue. See for instance
>
http://groups.google.com/groupshl=it&threadm=32DAD544.7983%40student.uq.edu.
au&rnum=2&prev=/groups%3Fhl%3Dit%26q%3Dc%252B%252B%2Bstd%253A%253A
null%2Boverload]

(This link didn't work for me - and yes I did paste
it back together - but I have seen recent discussions
on the subject.)

I like your proposal because it was clear and didn't
get bogged down in the way that the other discussions
seemed to. Sorry if I confused things a little with my
std::null suggestion - you should probably just go
with 0p and NULL in order to make the proposal
more palatable to the standards committee. Then
it is only the null_type identifier that could cause
reasonable code to break.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.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://www.research.att.com/~austern/csc/faq.html                ]

Garry Lancaster:
> > No-one can have previously defined std::null!

Robb:
> That not completely true, a namespace can be broken up, so someone
> could have difined a std::null. It not likly, but there may be some
> code that does it.

std is special. From the standard:

"[lib.reserved.names] 17.4.3.1 Reserved names
1 It is undefined for a C + + program to add declarations
or definitions to namespace std or namespaces
within namespace std unless otherwise specified."

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.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://www.research.att.com/~austern/csc/faq.html                ]

"Garry Lancaster" <glancaster@ntlworld.com> wrote in message news:<hn7i8.12487$Bv3.1981331@news6-win.server.ntlworld.com>...
> Garry Lancaster:
> > > No-one can have previously defined std::null!
>
> Robb:
> > That not completely true, a namespace can be broken up, so someone
> > could have defined a std::null.

> Garry Lancaster:
> std is special. From the standard:
>
> "[lib.reserved.names] 17.4.3.1 Reserved names
> 1 It is undefined for a C++ program to add declarations
> or definitions to namespace std or namespaces
> within namespace std unless otherwise specified."
>


ok, I didn't realize that namespace std was a reserved keyword. I like
to get a copy of the standard, but i don't have enough $$ (I'm 18 yrs.
and don't have a job).

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

"Garry Lancaster" <glancaster@ntlworld.com> wrote in message news:<Wplh8.57729$Hg1.9448286@news6-win.server.ntlworld.com>...

[snip...]

> > As F. Glassborow has pointed out on
> > c.l.c++.m it should possibly be an incomplete type.
>
> I don't see the rationale for making it incomplete
> (either in my head or in Francis's post). I hope it
> hasn't got anything to do with varargs functions ;-)

Please see below :)

[snip...]

>
> > >> char * p = 0; // (im)possibly deprecated
>
[...]
>
> I think you misunderstand; "(im)possibly deprecated"
> implies you are not sure whether it is possible to
> deprecate or not. I'm saying it is (because
> deprecated != removed).
>

Oh, yes. You are perfectly right, sorry :(

>
> Incidentally, although I appreciate the advantage that
> 0p gives over null, I'm still pining for the latter. What
> about
>
> // In a standard header somewhere.
> namespace std
> {
>     const null_type null = 0p;
> }
>
> ?
>
> No-one can have previously defined std::null!
>

Oh! :-O That's why you don't want an incomplete type... I didn't
suspect you also liked a constant "named" null! :) This has made me
think... Anyhow, Francis note concerned null, not 0p, and as far as I
understood it, I think the reason for the type incompleteness was to
prohibit instantiating the type itself. In other words to have "null"
to be the only value of that type. It seems to me the same property is
desirable for 0p, but this prevents you to define

const null_type null = 0p;

Of course ad-hoc rules allowing only one "const null_type null"
definition and only in namespace std could be introduced but I think
nobody would like that.


It seems that this "null macro question" continues slipping out of our
hands (the revenge of C? :) ). I would be (quite) satisfied with
something like:

template <typename T>
class null {

public:
static T* const p = value;

private:
 null();
 null(const null&);

};


but this isn't allowed either. So what can we do?

Genny.

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

Garry Lancaster:
> > // In a standard header somewhere.
> > namespace std
> > {
> >     const null_type null = 0p;
> > }
> >
> > ?
> >
> > No-one can have previously defined std::null!

Gennaro Prota:
> Oh! :-O That's why you don't want an incomplete type... I didn't
> suspect you also liked a constant "named" null! :)

I did give other reasons for wanting a complete
type earlier in the discussion and I also think
- why make it more complicated than it need be?
But, yes, my preference for null has some
influence. Really, it boils down to an aesthetic
preference.

if( foo == null )

is just so much more beautiful than

if( foo == 0p )    // excuse me?

or even

if( foo == NULL )    // stop *SHOUTING*!

don't you think? ;-)

It makes it look like Java too (whether that makes
it more or less beautiful I'll let others decide...)

But I suspect 0p might get past the committee
where null, or even std::null, probably wouldn't
because of the code breakage issue.

> This has made me
> think... Anyhow, Francis note concerned null, not 0p, and as far as I
> understood it, I think the reason for the type incompleteness was to
> prohibit instantiating the type itself. In other words to have "null"
> to be the only value of that type. It seems to me the same property is
> desirable for 0p, but this prevents you to define
>
> const null_type null = 0p;
>
> Of course ad-hoc rules allowing only one "const null_type null"
> definition and only in namespace std could be introduced but I think
> nobody would like that.

Then again, if someone really wants to write

null_type foo = 0p;

why stop them?

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.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://www.research.att.com/~austern/csc/faq.html                ]

On Mon,  4 Mar 2002 15:55:36 GMT, "Garry Lancaster"
<glancaster@ntlworld.com> wrote:

>Gennaro Prota:
>> Hi everybody,
>>
>>  in regards to the well-known "NULL macro/0 literal and pointers"
>> issues, what about introducing a special form of literal such 0p?
>
[...]
>
>> It would be a null pointer constant (possibly of
>> some (special) type),
>
>Hopefully of a type that I can overload on.

And specialize templates on. As F. Glassborow has pointed out on
c.l.c++.m it should possibly be an incomplete type.

[snip...]
>
>> char * p = 0; // (im)possibly deprecated
>
Yes, this is why I wrote "(im)possibly" in the comment :) Anyhow that
use would be discouraged in favor of the new better alternative.

Genny.

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

Gennaro Prota:
> >> It would be a null pointer constant (possibly of
> >> some (special) type),

Garry Lancaster:
> >Hopefully of a type that I can overload on.

Gennaro Prota:
> And specialize templates on.

Exactly.

> As F. Glassborow has pointed out on
> c.l.c++.m it should possibly be an incomplete type.

I don't see the rationale for making it incomplete
(either in my head or in Francis's post). I hope it
hasn't got anything to do with varargs functions ;-)

Even if it is incomplete I can still overload on it
like so:

bool operator==(const my_type& lhs, const null_type& rhs);

so all is not lost, but it seems a little artificial that

bool operator==(my_type lhs, null_type rhs);

wouldn't work.

> >> char * p = 0; // (im)possibly deprecated

>>There's no way it can be removed from the language
>>given the amount of code about that relies on it.
>>However, while there is some disagreement over the
>>exact meaning of deprecation, it certainly doesn't mean
>>immediate removal. (Personally I reckon "We'd love
>>to remove it but we can't because of backwards
>>compatibility" fits quite well, but it isn't exactly
>>standardese.) So, it would be OK to deprecate.

> Yes, this is why I wrote "(im)possibly" in the comment :)

I think you misunderstand; "(im)possibly deprecated"
implies you are not sure whether it is possible to
deprecate or not. I'm saying it is (because
deprecated != removed).

> Anyhow that
> use would be discouraged in favor of the new better alternative.

That is, more or less, what deprecated means.

Incidentally, although I appreciate the advantage that
0p gives over null, I'm still pining for the latter. What
about

// In a standard header somewhere.
namespace std
{
    const null_type null = 0p;
}

?

No-one can have previously defined std::null!

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.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://www.research.att.com/~austern/csc/faq.html                ]

[snip]
> Incidentally, although I appreciate the advantage that
> 0p gives over null, I'm still pining for the latter. What
> about
>
> // In a standard header somewhere.
> namespace std
> {
>     const null_type null = 0p;
> }
>
> ?
>
> No-one can have previously defined std::null!

That not completely true, a namespace can be broken up, so someone
could have difined a std::null. It not likly, but there may be some
code that does it.

>
> Kind regards
>
> Garry Lancaster
> Codemill Ltd
> Visit our web site at http://www.codemill.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://www.research.att.com/~austern/csc/faq.html                ]

Hi everybody,

 in regards to the well-known "NULL macro/0 literal and pointers"
issues, what about introducing a special form of literal such 0p?

It would be a null pointer constant (possibly of some (special) type),
convertible to a pointer or pointer to member type but not to int
types.

Here are (by examples to keep this post short) some rules:


int * = 3p; // illegal: only 0p admitted, of course.

void f(A* pa);
void f(B* pb);
void f(int n);

char * p = 0p; // ok
int n = 0p; // wrong
char * p = 0; // (im)possibly deprecated

f(0); // calls f(int), sigh :(
f(0p); // ambiguous: f(A*) or f(B*)?

#define NULL 0p /*valid */


P.S.: of course one could introduce a 0m for pointer-to-members (as
well as another literal to distinguish pointer to functions), but
maybe this is an unnecessary complication


Genny.

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

Gennaro Prota:
> Hi everybody,
>
>  in regards to the well-known "NULL macro/0 literal and pointers"
> issues, what about introducing a special form of literal such 0p?

This has been discussed a lot recently on the
newsgroups. I'm in favour of it. I'd prefer null
to be the name of the literal, but I guess 0p
has the advantage that no-one can already
have used it.

> It would be a null pointer constant (possibly of
> some (special) type),

Hopefully of a type that I can overload on.
null_type?

> convertible to a pointer or pointer to member type but not to int
> types.

Yes!

> Here are (by examples to keep this post short) some rules:
>
>
> int * = 3p; // illegal: only 0p admitted, of course.
>
> void f(A* pa);
> void f(B* pb);
> void f(int n);
>
> char * p = 0p; // ok
> int n = 0p; // wrong

Yes!

> char * p = 0; // (im)possibly deprecated

There's no way it can be removed from the language
given the amount of code about that relies on it.
However, while there is some disagreement over the
exact meaning of deprecation, it certainly doesn't mean
immediate removal. (Personally I reckon "We'd love
to remove it but we can't because of backwards
compatibility" fits quite well, but it isn't exactly
standardese.) So, it would be OK to deprecate.

> f(0); // calls f(int), sigh :(
> f(0p); // ambiguous: f(A*) or f(B*)?
>
> #define NULL 0p /*valid */

This #define will break any code that relies on
NULL being convertible to an int. I think that's
acceptable and indeed, is one of the aims of
the proposal. Such code deserves to die, noisily
if possible. Anyone got a counter-example?

> P.S.: of course one could introduce a 0m for pointer-to-members (as
> well as another literal to distinguish pointer to functions), but
> maybe this is an unnecessary complication

I think you are right that this is unnecessary.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.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://www.research.att.com/~austern/csc/faq.html                ]

In article <sd758uksolb1evhogi5gvk1lt5v7enc4bp@4ax.com>,
Gennaro Prota  <gennaro_prota@yahoo.com> wrote:
>
>Hi everybody,
>
> in regards to the well-known "NULL macro/0 literal and pointers"
>issues, what about introducing a special form of literal such 0p?
>
>It would be a null pointer constant (possibly of some (special) type),
>convertible to a pointer or pointer to member type but not to int
>types.

I don't think it would buy you very much.

If you use 0 or NULL in a context that expects a pointer (e.g. calling a
prototyped function) it will be converted to the appropriate pointer type
automatically, just as 0p would be.

If you use 0 or NULL in a context where the target type isn't known
(e.g. calling a varargs function), you still need to cast to the
appropriate type.  0p won't help because it won't necessarily be the same
pointer type that the callee expects.  Even if we decide that pointer
arguments to varargs functions must always be passed as void*, and 0p
evaluates to this type, what does this buy you over writing (void*)0 or
(void*)NULL, other than saving a few keystrokes?

The same goes for functions that are overloaded for both integer and
pointer types.  0p will avoid it the default behavior of preferring the
integer function, but you can do that just as well by writing (<type>*)0.

Finally, if we do decide to introduce a new literal, it might as well be
spelled "null" rather than "0p".  The latter notation suggests generality,
such as 3p, that you said should *not* be permitted.

--
Barry Margolin, barmar@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On Mon,  4 Mar 2002 21:00:45 GMT, Barry Margolin <barmar@genuity.net>
wrote:

>In article <sd758uksolb1evhogi5gvk1lt5v7enc4bp@4ax.com>,
>Gennaro Prota  <gennaro_prota@yahoo.com> wrote:
>>
>>Hi everybody,
>>
>> in regards to the well-known "NULL macro/0 literal and pointers"
>>issues, what about introducing a special form of literal such 0p?
>>
>>It would be a null pointer constant (possibly of some (special) type),
>>convertible to a pointer or pointer to member type but not to int
>>types.
>
>I don't think it would buy you very much.
>

0p has basically the same purpose of a new keyword (which is
frequently proposed). The advantage is: it doesn't break any code.

As to variadic functions, there's very little we can do: the only
improvement of 0p against a plain 0 (but, I say it again, not against
a null keyword) could be, for instance, to explicitly forbid passing
an uncasted 0p through the ellipsis.

Genny.

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