home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / cplus / 18140 < prev    next >
Encoding:
Text File  |  1992-12-17  |  2.3 KB  |  56 lines
  1. Path: sparky!uunet!olivea!spool.mu.edu!yale.edu!ira.uka.de!slsvaat!josef!kanze
  2. From: kanze@us-es.sel.de (James Kanze)
  3. Newsgroups: comp.lang.c++
  4. Subject: NULL in C++ (was: Is this a compiler bug?)
  5. Message-ID: <KANZE.92Dec17201857@slsvdnt.us-es.sel.de>
  6. Date: 18 Dec 92 04:18:57 GMT
  7. References: <1992Dec8.183122.1@vax1.bham.ac.uk> <KANZE.92Dec11165414@slsvdnt.us-es.sel.de>
  8.     <1992Dec11.193023.27787@news2.cis.umn.edu>
  9.     <1992Dec14.212823.20514@microsoft.com>
  10. Sender: news@us-es.sel.de
  11. Organization: SEL
  12. Lines: 41
  13. In-Reply-To: jimad@microsoft.com's message of 14 Dec 92 21:28:23 GMT
  14.  
  15. In article <1992Dec14.212823.20514@microsoft.com> jimad@microsoft.com
  16. (Jim Adcock) writes:
  17.  
  18.    [The thread that started this discussion deleted...]
  19. |> I think the confusion lies in assuming that ((void*)0) could be an
  20. |> acceptable implementation of NULL in C++.  ((void*)0) is acceptable
  21. |> in C.  It is not acceptable in C++.  The rules of pointer type compatibility
  22. |> have changed, and are more restrictive in C++.  Thus ((void*)0) no longer
  23. |> flies.  This is a source of frequent trouble for C++ programmers trying to
  24. |> use old C .h files.
  25.  
  26. This brings up another point.
  27.  
  28. The C++ committee have aready changed wchar_t into a true type, rather
  29. than the typedef it was in C.  Why couldn't NULL become a true
  30. reserved word in C++?  Then we wouldn't have to worry about whether it
  31. was defined in a compatible way.
  32.  
  33. Logically, this should lead to the deprication of assigning 0 to a
  34. pointer, or comparing a pointer to 0.  The NULL pointer would then be
  35. represented as NULL, and not 0, and would unambiguously be a pointer.
  36.  
  37. And of course, this would solve the ambiguity problem with overloaded
  38. functions:
  39.  
  40.     extern void    f( int ) ;
  41.     extern void    f( void* ) ;
  42.  
  43.     f( 0 ) ;    //  Currently ambiguous, should call f( int )
  44.     f( NULL ) ;    //  Currently ambiguous, should call f( void* )
  45.  
  46. Somebody will no doubt prove me wrong, but I can't think of a single
  47. program that this would break (supposing the depricated implicit
  48. conversion).  And the depricated conversion wouldn't hinder the above
  49. from working, since an exact match would be preferred over a
  50. conversion.
  51. --
  52. James Kanze                             email: kanze@us-es.sel.de
  53. GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
  54. Conseils en informatique industrielle --
  55.                    -- Beratung in industrieller Datenverarbeitung
  56.