home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 12864 < prev    next >
Encoding:
Internet Message Format  |  1992-08-25  |  2.8 KB
  1. Path: sparky!uunet!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!tmb
  2. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Is there a way to flag errors when an automatic array is returned
  5. Message-ID: <TMB.92Aug25183032@arolla.idiap.ch>
  6. Date: 25 Aug 92 22:30:32 GMT
  7. References: <3499@babcock.cerc.wvu.wvnet.edu> <KENDALL.92Aug24123852@pen.centerline.com>
  8.     <1992Aug25.135401.17891@bnr.ca>
  9. Sender: news@ai.mit.edu
  10. Reply-To: tmb@idiap.ch
  11. Followup-To: comp.lang.c++
  12. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  13.     Perceptive)
  14. Lines: 37
  15. In-reply-to: holiday@bnr.ca's message of 25 Aug 92 13:54:01 GMT
  16.  
  17. In article <1992Aug25.135401.17891@bnr.ca> holiday@bnr.ca (Matthew Holiday) writes:
  18.  
  19.    I'm not sure that it would be possible to verify at compile time that a returned
  20.    pointer isn't a pointer to a local variable.  It is possible to determine this at
  21.    run time -- just check all returned pointers to verify that the address isn't
  22.    within or below the stack frame about to be destroyed (you may also need to check
  23.    that it's within the stack area, so that you don't accidentally trap on valid heap
  24.    pointers, if the heap is below the stack in the address space, etc., etc.).  It's
  25.    probably about as expensive as run-time array bounds checks, which aren't in C or 
  26.    C++ either -- they don't fit the C/C++ design philosophy.
  27.  
  28. I suspect array bounds checks are not in C++ because they would be
  29. virtually impossible to add in a backwards compatible fashion. At the
  30. root of the problem is the fact that C "pointers" are used for
  31. multiple purposes, including displaced arrays and locatives. In
  32. languages that support them, array bounds checks can usually be
  33. disabled locally or optimized away, so there is no great cost
  34. associated with them (and they are _very_ useful). I suspect that in
  35. the long run, emulating array bounds checks in C++ classes is going to
  36. be less efficient than if C++ supported them as a built-in.
  37.  
  38. Checking against returning pointers to automatic variables, however,
  39. is very difficult in most languages. The situation is not at all
  40. analogous to array bounds checks. The reason is that you might also
  41. "return" pointers by storing them inside other data structures that
  42. you return, or even via global variables. The solution to this problem
  43. adopted by most programming languages is to use a combination of
  44. copying and garbage collection. Small data structures are allocated on
  45. the stack and copied upon return, while large data structures are
  46. allocated on the heap and cleaned up via a garbage collector if it
  47. turns out that they are no longer needed after the function returns.
  48.  
  49. (Some modern language implementations have done away with the stack
  50. altogether, allocating even "stack frames" on the heap; the jury is
  51. still out on whether that is a good idea.)
  52.  
  53.                     Thomas.
  54.