home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / cplus / 1986 < prev    next >
Encoding:
Text File  |  1993-01-06  |  2.1 KB  |  38 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!microsoft!wingnut!jimad
  3. From: jimad@microsoft.com (Jim Adcock)
  4. Subject: Re: Nested functions (was: Re: Zero-length structures and pointer comparisons)
  5. Message-ID: <1993Jan06.193256.6590@microsoft.com>
  6. Date: 06 Jan 93 19:32:56 GMT
  7. Organization: Microsoft Corporation
  8. References: <1992Dec16.150144.6004@ucc.su.OZ.AU> <BzDJHu.t2@fru <4048@hpwala.wal.hp.com>
  9. Lines: 27
  10.  
  11. In article <4048@hpwala.wal.hp.com> pabloh@hpwala.wal.hp.com (Pablo Halpern ) writes:
  12. |Absolute orderings are a slightly different matter.  In the case of < and
  13. |>, one might expect a significant performance improvement if the pointers
  14. |are assumed to point into the same array, since the segment part can be
  15. |ignored even for far pointers.  A ptrcmp() function might be worthwhile and
  16. |should present no special implementation problems for segmented
  17. |architectures.  However, systems (like the lisp machine) where pointers
  18. |change behind the program's back DO present a problem since the
  19. |bit-pattern-based ordering could change even if the equality/inequality
  20. |property does not change.  This would argue against *requiring* a ptrcmp()
  21. |function.
  22.  
  23. Except some OS's using segmented architectures implement movable segments, 
  24. in which case the problem becomes the same as lisp machines --
  25. "pointers change behind the programmers back"
  26.  
  27. My claim is that in either of these cases the pointers *aren't* changing --
  28. they still point at the same objects.  What is changing is the underlying
  29. implementation of the pointer, which is an implementation issue not
  30. a language issue.  Casting pointers to and from int remains as always
  31. implementation dependent.  The only issue in question is whether we
  32. should introduce a new requirement on OS's that the OS must maintain
  33. a total ordering on their objects.  Clearly IMHO this would represent
  34. a stumbling block to many OS's, such a the lisp machines, movable segment
  35. OS's and OO databases.  Making such a new requirement on C++ would make
  36. C++ not reasonably portable to these systems.  The question then is
  37. whether or not the standard C++ language should exist on such machines.
  38.