From -5556223640977217516 X-Google-Language: ENGLISH,ASCII X-Google-Thread: f78e5,f1dec9ce20a9c98f X-Google-Attributes: gidf78e5,public From: James.Kanze@dresdner-bank.com Subject: Re: null pointers (was: Why's of C++ -- Part 1) Date: 1999/08/19 Message-ID: <7phb3o$3a8$1@nnrp1.deja.com>#1/1 X-Deja-AN: 514759643 X-NNTP-Posting-Host: 193.194.7.84 Approved: stephen.clamage@sun.com (comp.std.c++) References: <7opqvm$vpa$1@news.hal-pc.org> <37B7C714.44E4EFB4@lucent.com> <7pcoem$105@abyss.West.Sun.COM> <7pdh80$qaf$1@engnews1.eng.sun.com> X-UID: 0000000001 X-Status: $$$T X-Http-User-Agent: Mozilla/4.06 [de] (WinNT; I) X-Http-Proxy: 1.0 x39.deja.com:80 (Squid/1.1.22) for client 193.194.7.84 Organization: Deja.com - Share what you know. Learn what you don't. X-Article-Creation-Date: Thu Aug 19 16:24:40 1999 GMT X-MyDeja-Info: XMYDJUIDkanze Newsgroups: comp.std.c++ Originator: clamage@taumet In article <7pdh80$qaf$1@engnews1.eng.sun.com>, clamage@eng.sun.com (Steve Clamage) wrote: > stanley@West.Sun.COM (Stanley Friesen [Contractor]) writes: > >The special case would be exactly and only the token sequence "(void > >*)0". There is no reason to extend it to integers that happen to > >have the value zero. That is not particularly useful. > But there is utility in accepting the same null pointer constants that > C accepts. > In C, any constant integer expression with value 0, or that value cast > to void*, is a null pointer constant. I don't see the benefit in > accepting (void*)0 but rejecting, for example, ((void*)0L). Agreed. *If* any such extension is considered, it should use the same criteria as C: an integral constant expression evaluating to zero , or such an expression cast to void*. While I would never really expect to see anything other than 0, 0L or ((void*)0), I can see no real value in restricting it to a specific token sequence. The more I think about it, the more I think that that (and requiring NULL to be defined as "((void*)0)" is the only change needed. While void* does not normally implicitly convert to other pointer types in C++, neither does 0. And while the type of ((void*)0) is void*, defining it as a null pointer constant would permet the conversion in this special case. Having said that, of course, I should point out that the *only* real win is to ensure that NULL can only be used in a pointer context. It doesn't stop any of the existing misuses of 0 or implicit conversion to bool. It does mean that people like myself who prefer NULL can use it without worrying that it will have unexpected repercusions on function overloading (f(NULL) calling f(int)). I now remember why a new type was considered preferable: it could be declared illegal to pass an instance of this type to a vararg. Requiring NULL to have this type would mean that errors like: execl( "Prog" , "Prog" , "anArg" , NULL ) ; would be flagged by the compiler, rather than simply resulting in undefined behavior. (On second thought, I'm not sure whether this is a good idea. Vararg functions are fairly rare, and most of the ones I've seen are like the above, and take either void* or char*. Given that the standard more or less requires the same representation of void* and char*, it is hard to imagine an implementation where the undefined behavior in the above case would do anything but work. And I'm sure that there is a large body of code which does just this, at least in C.) Anyway, one of the reasons my proposal was so simple was the lack of time. This is no longer a reason, as we have at least a couple of years before any new proposal can be considered. I'd be interested in seeing one which took the route of the separate type, if only to see what the impact really is. -- James Kanze mailto: James.Kanze@dresdner-bank.com Conseils en informatique orient�e objet/ Beratung in objekt orientierter Datenverarbeitung Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627 Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]