home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / modula2 / 1721 < prev    next >
Encoding:
Internet Message Format  |  1993-01-22  |  3.2 KB
  1. Path: sparky!uunet!psgrain!puddle!f590.n139.z1.fidonet.org!Sean.Wilson
  2. From: Sean.Wilson@f590.n139.z1.fidonet.org (Sean Wilson)
  3. Sender: ufgate@puddle.fidonet.org (newsout1.26)
  4. Newsgroups: comp.lang.modula2
  5. Subject: JPI Compiler bug?
  6. Message-ID: <40647.2B5FB766@puddle.fidonet.org>
  7. Date: Thu, 21 Jan 93 11:17:52 PDT
  8. Organization: FidoNet node 1:139/590 - PMI BBS, Green Bay WI
  9. Lines: 105
  10.  
  11.  
  12. MO>   Here`s a question for networked JPI-supporters:
  13.  
  14. MO>   We tried to `overload` the NEW-procedure by implementing the module
  15.  
  16. MO>   DEFINITION MODULE XStorage;
  17.  
  18. MO>   FROM SYSTEM IMPORT ADDRESS;
  19.  
  20. MO>   BEGIN
  21.  
  22. MO>   ...
  23.  
  24. MO>   PROCEDURE NEW ( VAR adr : ADDRESS );
  25. MO>   BEGIN
  26. MO>      ALLOCATE( adr, SIZE(adr^) );
  27. MO>   END NEW.
  28.  
  29. MO>   END XStorage.
  30.  
  31.  
  32. MO>   Our intention was to avoid substituting NEW-calls in a number of source-MO>   files by ALLOCATE() calls. This doesn`t work, because the compiler MO>   allocates 4 bytes of memory, although the amount of x bytes, required MO>   for the data structure adr points at, should be allocated, eg.
  33.  
  34. MO>   TYPE
  35. MO>      RecordPtr = POINTER TO Record;
  36. MO>      Record    = RECORD
  37. MO>                     str : ARRAY [0..79] OF CHAR;
  38. MO>                     int : INTEGER;
  39. MO>                  END;
  40.  
  41. MO>   XStorage.NEW( adr ) allocates 4 bytes of memory. An explicit MO>   ALLOCATE()-call works.
  42.  
  43.  
  44. MO>   Got the point?
  45.  
  46. MO>   Marcus
  47.  
  48. This isn't a compiler bug, overloading NEW() cannot be done in this way. When the compiler encounters a call to NEW() it will normally expand this to a call of the form:
  49.  
  50.         ALLOCATE(adr, SIZE(adr^));
  51.  
  52. as you have determined.  In order for this to work, the compiler must have information about the type of the variable in the NEW() call.  This size information is not passed to your overloaded NEW().
  53.  
  54. The solution is to overload not the NEW() procedure but the ALLOCATE() and DEALLOCATE() procedures.  Since these are not compiler generated you can be sure of getting all the relevant information, you can then do whatever you like in your own code.  e.g:
  55.  
  56. DEFINITION MODULE XStorage;
  57.  
  58. PROCEDURE ALLOCATE(VAR adr: ADDRESS; len: CARDINAL);
  59. PROCEDURE DEALLOCATE(VAR adr: ADDRESS; len: CARDINAL);
  60.  
  61. END XStorage.
  62.  
  63. IMPLEMENTATION MODULE XStorage;
  64.  
  65.   IMPORT Storage;
  66.  
  67. PROCEDURE ALLOCATE(VAR adr: ADDRESS; len: CARDINAL);
  68. BEGIN
  69.   (* ... *)
  70.   Storage.ALLOCATE(adr, len);
  71.   (* ... *)
  72. END ALLOCATE;
  73.  
  74. PROCEDURE DEALLOCATE(VAR adr: ADDRESS; len: CARDINAL);
  75. BEGIN
  76.   (* ... *)
  77.   Storage.DEALLOCATE(adr, len);
  78.   (* ... *)
  79. END DEALLOCATE;
  80.  
  81. END XStorage.
  82.  
  83.  
  84. MODULE Tst;
  85.  
  86.   FROM XStorage IMPORT ALLOCATE, DEALLOCATE;
  87. (* The above line replaces the following line in your code.     *) (* FROM Storage IMPORT ALLOCATE, DEALLOCATE;                    *)
  88.  
  89.  
  90.   TYPE
  91.     RecordPtr = POINTER TO Record;
  92.     Record    = RECORD
  93.       str : ARRAY [0..79] OF CHAR;
  94.       int : INTEGER;
  95.     END;
  96.  
  97.   VAR
  98.     rec : RecordPtr;
  99. BEGIN
  100.   (* In the following call the compiler still generates a call  *)
  101.   (* to ALLOCATE, but this is resolved by XStorage.ALLOCATE     *)
  102.   (* rather than Storage.ALLOCATE.                              *)
  103.   NEW(rec);
  104. END Tst.
  105.  
  106. Best regards
  107.   Sean.
  108.  
  109. ___
  110.  X PQ-Under-Trial 2.15 X If you ain't got it then you ain't communicatin'.
  111.  
  112.  
  113. --  
  114. uucp: uunet!m2xenix!puddle!139!590!Sean.Wilson
  115. Internet: Sean.Wilson@f590.n139.z1.fidonet.org
  116.