Added upstream from http://ftp.icm.edu.pl/pub/loglan/
[loglan.git] / HTML / MicroMan / Programm.htm
1 <!doctype html public "-//IETF//DTD HTML//EN">\r
2 <HTML>\r
3 \r
4 <HEAD>\r
5 \r
6 <TITLE>Programmed deallocation</TITLE>\r
7 \r
8 <META NAME="GENERATOR" CONTENT="Internet Assistant for Word 1.0Z">\r
9 <META NAME="AUTHOR" CONTENT="NOM">\r
10 </HEAD>\r
11 \r
12 <BODY>\r
13 \r
14 <H4><U><I>Loglan 82, A micro-manual of the programming language\r
15 - Basic constructs and facilities</I></U></H4>\r
16 \r
17 <H1><IMG ALIGN=MIDDLE SRC="gifs/logo2.gif"> 11) Programmed deallocation\r
18 </H1>\r
19 <HR>\r
20 \r
21 <P>\r
22 The classical methods implemented to deallocate class objects\r
23 are based on reference counters or garbage collection. Sometimes\r
24 the both methods may be combined. A reference counter is a system\r
25 attribute holding the number of references pointing to the given\r
26 object. Hence any change of the value of a reference variable\r
27 X is followed by a corresponding increase or decrease of the value\r
28 of its reference counter. When the reference counter becomes equal\r
29 0, the object can be deallocated.\r
30 <P>\r
31 The deallocation of class objects may also occur during the process\r
32 of garbage collection. During this process all unreferenced objects\r
33 are found and removed (while memory may be compactified). In order\r
34 to keep the garbage collector able to collect all the garbage,\r
35 the user should clear all reference variables , i.e. set to None,\r
36 whenever possible. This system has many disadvantages. First of\r
37 all, the programmer is forced to clear all reference variables,\r
38 even those which are of auxiliary character. Moreover, garbage\r
39 collector is a very expensive mechanism and thus it can be used\r
40 only in emergency cases.\r
41 <P>\r
42 In LOGLAN a dual operation to the object generator, the so-called\r
43 object deallocator is provided. Its syntactic form is as follows:\r
44 <P>\r
45 <IMG SRC="gifs/pd01.gif"> \r
46 <P>\r
47 where X is a reference expression. If the value of X points to\r
48 no object (none) then kill(X) is equivalent to an empty statement.\r
49 If the value of X points to an object O, then after the execution\r
50 of kill(X), the object O is deallocated. Moreover all reference\r
51 variables which pointed to O are set to none. This deallocator\r
52 provides full <I>security</I>, i.e. the attempt to access the\r
53 deallocated object O is checked and results in a run-time error.\r
54 <P>\r
55 For example:\r
56 <P>\r
57 <IMG SRC="gifs/pd02.gif"> \r
58 <P>\r
59 causes the same run-time error as:\r
60 <P>\r
61 <IMG SRC="gifs/pd03.gif"> \r
62 <P>\r
63 The system of storage management is arranged in such a way that\r
64 the frames of killed objects may be immediately reused without\r
65 the necessity of calling the garbage collector, i.e. the relocation\r
66 is performed automatically. There is nothing for it but to remember\r
67 not to use remote access to a killed object. (Note that the same\r
68 problem appears when remote access X.W is used and X=none).\r
69 <P>\r
70 Example:\r
71 <P>\r
72 Below a practical example of the programmed deallocation is presented.\r
73 Consider class Bst (p.7). Let us define a procedure that deallocates\r
74 the whole tree and is called with the termination of the class\r
75 Bst.\r
76 <P>\r
77 <IMG SRC="gifs/pd04.gif"> \r
78 <P>\r
79 Bst may be applied as a prefix:\r
80 <P>\r
81 <IMG SRC="gifs/pd05.gif"> \r
82 <P>\r
83 and automatically will cause the deallocation of the whole tree\r
84 after return to call kill_all(root) from the prefixed block.\r
85 <P>\r
86 To use properly this structure by remote accessing one must call\r
87 kill_all by himself:\r
88 <P>\r
89 <IMG SRC="gifs/pd06.gif"> \r
90 <P>\r
91 Finally note that deallocator kill enables deallocation of array\r
92 objects, and suspended coroutines and processes as well (cf p.13).\r
93 <HR>\r
94 \r
95 <P><hr>\r
96 <A HREF="Protecti.htm"><IMG SRC="gifs/PrevPage.gif"></A>\r
97 <A HREF="HomePage.html"><IMG SRC="gifs/HomePage.gif"></A> \r
98 <A HREF="Exceptio.htm"><IMG SRC="gifs/NextPage.gif"></A> <HR>\r
99 \r
100 <ADDRESS>\r
101 Last update 02/07/95 \r
102 </ADDRESS>\r
103 \r
104 <ADDRESS>\r
105 Comments, suggestions and critiques are welcome to : <A HREF="mailto:linfo062@crisv2.univ-pau.fr">linfo062@crisv2.univ-pau.fr</A>\r
106 \r
107 </ADDRESS>\r
108 \r
109 </BODY>\r
110 \r
111 </HTML>\r