Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!unido!fauern!lan!tensi
From: tensi@lan.informatik.tu-muenchen.dbp.de (Thomas Tensi)
Newsgroups: comp.lang.modula2
Subject: Re: Generic Lists in Modula-2
Message-ID: <4007@tuminfo1.lan.informatik.tu-muenchen.dbp.de>
Date: 17 Aug 90 09:38:01 GMT
References: <462.26C2767E@puddle.fidonet.org>
Sender: news@lan.informatik.tu-muenchen.dbp.de
Organization: Inst. fuer Informatik, Technische Univ. Muenchen, West Germany
Lines: 47
In-reply-to: Peter.M..Perchansky@f101.n273.z1.fidonet.org's message of 9 Aug 90 03:42:22 GMT

Hello Peter,

one problem with your deque module
(Peter.M..Perchansky@f101.n273.z1.fidonet.org's message of 9 Aug 90 03:42:22
GMT)
is that of storage reclamation for more complicated structures (e.g. deques
of deques).

Whenever you delete an element in your deque only the space of the element
itself is deallocated. This doesn't matter for data like records, arrays or
simple data types. But when this element is a pointer to something, the whole
information accessible from this pointer is lost and remains as garbage on the heap.

Of course you can say: "when I 'DestroyDeque' something, I know that the
elements involved are dynamic data structures and I deallocate them first".
When you do that everything is fine, but how about a callback procedure
installed when defining the deque? like that

          ...
  IMPORT SYSTEM;

  TYPE CallBackProcType = PROCEDURE (SYSTEM.ADDRESS);

  PROCEDURE CreateDeque (VAR deque: Deques;
                         CallBackProc : CallBackProcType);

          ...

This procedure is installed specific to any deque defined (just another
component of the deque record) and is called whenever an element from deque is
discarded (similar to your DEALLOCATE(node^.contents...)). So you get nearly
automatic storage reclamation without having to intersperse your code with
delete operations for your element data type.

The ugly thing about this solution is that SYSTEM is again used in the
definition module. But that's the way with genericity in MODULA-2...

Thomas Tensi

------------------------------------------------------------------------------
Thomas Tensi, Institut fuer Informatik, Technische Univ. Muenchen,
Arcisstr. 21, 8000 Muenchen 2, West Germany
        | E-Mail:
        | tensi@lan.informatik.tu-muenchen.dbp.de                (X.400)
        | tensi%lan.informatik.tu-muenchen.dbp.de@relay.cs.net   (arpa/csnet)
        | tensi%lan.informatik.tu-muenchen.dbp.de@unido.uucp     (uucp)
        | tensi%lan.informatik.tu-muenchen.dbp.de@ddoinf6.bitnet (bitnet)