home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / ada / 2500 < prev    next >
Encoding:
Internet Message Format  |  1992-08-31  |  3.0 KB
  1. Path: sparky!uunet!munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!cs.adelaide.edu.au!andrewd
  2. From: andrewd@cs.adelaide.edu.au (Andrew Dunstan)
  3. Newsgroups: comp.lang.ada
  4. Subject: Re: Could you forward this to Comp.Lang.Ada
  5. Message-ID: <8392@sirius.ucs.adelaide.edu.au>
  6. Date: 1 Sep 92 02:58:41 GMT
  7. References: <9208311113.AA21505@cs.NYU.EDU>
  8. Sender: news@ucs.adelaide.edu.au
  9. Lines: 46
  10. Nntp-Posting-Host: achilles.cs.adelaide.edu.au
  11.  
  12. In article <9208311113.AA21505@cs.NYU.EDU>, dewar (Robert Dewar) writes:
  13. |> Andrew Dunstan writes:
  14. |>  "Thanks for pointing this [the rule in 13.5(8)] out - I did actually look
  15. |>   in the LRM before I posted, but obviously not hard enough! Finding these
  16. |>   little things in the LRM is like looking for a needle in a haystack."
  17. |> 
  18. |> Well the RM takes many knocks, some deserved, but really! this is somewhat
  19. |> unfair. If I was wondering about the use of an address clause in Ada, I
  20. |> should think I would read section 13.5 of the reference manual, whose
  21. |> title is, reasonably helpfully "Address Clauses". Since this section is
  22. |> quite short (only 21 lines long plus a short example and a note), it would
  23. |> seem quite reasonable to read the full 21 lines. 3 of these lines (a
  24. |> separate paragraph, para (5), contain the restriction stated pretty clearly:
  25. |> 
  26. |>   "Address clauses should not be used to achieve overlays of objects or
  27. |>    overlays of program units. Nor should a given interrupt be linked to more 
  28. |>    than one entry. Any program using address clauses to achieve such an 
  29. |>    effect is erroneous."
  30.  
  31. Ok, my face is bright red! I looked at 13.1 and missed the reference to 13.5.
  32.  
  33.  
  34. |> 
  35. |> One final note, back to the original problem. The best general solution is
  36. |> to use access STRING for these kind of situations. Actually access STRING
  37. |> is a pretty reasonable type for the manipulation of variable length strings.
  38. |> Of course it means using the heap which you might want to avoid, but in that
  39. |> case, worry a little about using unconstrained returned values from functions
  40. |> at all -- many, but not all, implementations secretly use the heap anyway
  41. |> for this situation. So if you are writing portable code which wants to avoid
  42. |> using the heap, better to use an interface like GET_LINE, even if it is
  43. |> clunkier!
  44.  
  45. I have made the point to several people that using an access to string type
  46. is what I would do myself, but that I have seen code which does use
  47. address clauses to do what I suggested, notwithstanding that it is
  48. erroneous.
  49.  
  50. -- 
  51. #######################################################################
  52. #  Andrew Dunstan                   #   There's nothing good or bad   #
  53. #  Department of Computer Science   #   but thinking makes it so.     #
  54. #  University of Adelaide           #                                 #
  55. #  South Australia                  #          - Shakespeare          #
  56. #  net: andrewd@cs.adelaide.edu.au  #                                 #
  57. #######################################################################
  58.