Dec 222017
Implementation of a fully Generic Doubly-Linked List object, Heap Manager object, and other tidbits. Includes TP 5.5+ OOP source code.
File GENERICS.ZIP from The Programmer’s Corner in
Category Pascal Source Code
Implementation of a fully Generic Doubly-Linked List object, Heap Manager object, and other tidbits. Includes TP 5.5+ OOP source code.
File Name File Size Zip Size Zip Type
DOUBLINK.PAS 286 181 deflated
FLEXPNTR.PAS 525 299 deflated
FLEXPNTR.TPU 704 323 deflated
FLXARRAY.DOC 9877 3346 deflated
GENARRAY.TPU 5024 2103 deflated
GENDATUM.PAS 5206 1855 deflated
GENERICS.DOC 7033 3163 deflated
GENLIST.DOC 11947 3804 deflated
GENLIST.PAS 11059 3345 deflated
GENSTACK.PAS 2676 964 deflated
HEAPS.PAS 1984 616 deflated
HUGEARAY.TPU 6304 2671 deflated
H_ARRAYS.PAS 1182 518 deflated
LGENHEAP.PAS 4234 1253 deflated
LISTS.PAS 2231 723 deflated
L_HEAPS.PAS 3628 1072 deflated
MAXARRAY.DOC 10959 3443 deflated
MGENHEAP.TPU 4032 1686 deflated
NODESORT.PAS 1056 425 deflated
SRTFUNCS.PAS 968 403 deflated
STACKS.PAS 2610 1009 deflated
STAKDEMO.PAS 1197 483 deflated
TEST.PAS 1140 532 deflated
TESTHEAP.PAS 774 391 deflated
TESTLIST.PAS 914 354 deflated

Download File GENERICS.ZIP Here

Contents of the FLXARRAY.DOC file

****** The FlexArray and FlexStack Objects (and Descendants) *****

Design and Implementation --- Eric C. Wentz


2374 Antiqua Court
Reston, Va. 22091

Last Modification Date : 7-22-89


Design Objective(s):

(1) {FlexArray}

Implementation of a fully Generic Array-like Object,
Capable of all Array functions. Additionally, Dynamic
allocation and Re-Sizing should be incorporated to
enhance efficiency and utility.

(2) {FlexStack}

Implementation of a fully Generic Stack Object, capable
of all Stack functions for any Data type. Additionally,
Dynamic allocation and Re-Sizing would be nice.


FlexArrays and FlexStacks are limited to the maximum size which
GetMem can allocate to a single variable, or 65521 bytes.

As the FlexArray and the FlexStack are fundamentally defined
by use of Dynamically allocated arrays of un-typed bytes, it is
only possible to define them for similar-sized constituents. In
particular it will not be possible to declare a FlexArray of
Ancestor-Objects and then use it to contain different-sized
Descendant Objects. The user should be able to get around this by
declaring a FlexArray of pointers to such objects, but I have not
made any attempts to test this.

As (I believe) Turbo allocates the same number of bytes for each
variant of a Variant record, there should be no problems with
variant records.

Comments Regarding Primary Benefits

The FlexArray, in and of itself, brings nothing new to the user other then
the ability to Dynamically size (and grow or shrink) an array. In fact,
used simply as an array, the FlexArray is more clumsy then a normal
array. The importance of the FlexArray is not its mimicry of the normal
array, but the Genericity inherent in its implementation. By exploiting
this feature of the FlexArray, it is possible to define more abstract
Objects (such as the FlexStack) which require an Array as the fundamental
DataStructure WITHOUT REGARD TO DATATYPE. Using this concept, it is easy
to implement a stack (for instance) and NEVER again need to go through the
process of defining a stack, regardless of the type of variable which you
later find you need to stack. -- See Unit Stacks for more details.

ADDED NOTE: The methods used to implement FlexArrays WILL provide
the same accessing speed as normal arrays, even though
we must sacrifice the easier notation inherent to normal
arrays. Performance doesn't suffer by using FlexArrays!

Implementation {FlexArray} :

Unit GenArray; { Generic Arrays -- Maximum size 65521 bytes }

INTERFACE { NOT the entire Interface, but all needed definitions are here }

{ NOTE: FlexArrays are Indexed from 0 to MaxElements-1 }

FlexArray = Object

Procedure Create;
Procedure Init (MaxElements,ElementSize : Word); {Once CREATEd, you may}
Procedure Destroy; {Re-Use a FlexArray by}
{DESTROYing and then }
{Re-INITting it. }

Procedure Accept (Var El; Index,Size : Word); {Assign the Indexth El}
Procedure Retrieve (Var El; Index,Size : Word); {Get the Indexth El}

Procedure Copy (F : FlexArray); {Target MUST be CREATEd or DESTROYed}

Function MaxSize : Word; {Report Current Array Length}
Function ElemSize : Word; {Report Element Size}

Procedure ReSize (NewMaxElements : Word);
{Extend/Shrink to NewMaxElements}


IMPLEMENTATION { Not Reproduced }

Implementation {FlexStack} :

Unit GenStack; { FlexArray-Based Generic Stacks }

INTERFACE { NOT the entire Interface, but all needed definitions are here }

FlexStack = Object(FlexArray) {Dynamically allocated Stack}

Procedure Create;

Function Full : Boolean;
Function Depth : Word;
Function Empty : Boolean;

Procedure Copy (F : FlexStack);
Procedure ReSize (Num : Word); {Grow (or Shrink) by Num elements}

{NOTE: It is an Error to ReSize a FlexStack to Zero (or Negative)}

Procedure Push (Var El; Size : Word); {Size of El MUST match ElementSize}
Procedure Pop (Var El; Size : Word);
Procedure Top (Var El; Size : Word); {TOP does not POP the Stack}

(* Applicable inherited procedures and functions: *)

{ Procedure Init (MaxElements,ElementSize); }
{ Procedure Destroy; }
{ Function MaxSize : Word; }
{ Function ElemSize : Word; }


IMPLEMENTATION { Not Reproduced }


| \
| \
GenStack {other Stack-based structures (GENERIC)}
| \
| \
Stacks {Derived Application-level structures}


I have made considerable effort to anticipate all possible errors when
manipulating FlexArrays, and have incorporated a simple error procedure into
the implementation section of unit GenArray. It prints a simple diagnostic
message to the screen and HALTs the program. This "bonehead" strategy seems
to be sufficient for three reasons: (1) I BELIEVE that ALL conceivable errors
will be due to developmental errors. (2) I dislike the necessity of passing
boolean "fail" variables. (3) Enough statistical information methods are
provided to enable the user to define more sophisticated error checking and
recovery methods, if such is desired or needed by some situation which I have
not anticipated. -- For example Unit GenStack also incorporates an error
routine for stack-specific errors -- see below.


Attempted Init on Un-Created or Initialized FlexArray.
Insufficient Memory for Requested FlexArray.
Attempted Accept with Incorrect Size Variable.
Attempted Accept on Un-Initialized FlexArray.
Attempted Retrieve with Incorrect Size Variable.
Attempted Retrieve with Un-Initialized FlexArray.
Attempted Copy on Un-Created or Initialized FlexArray.
Attempted to ReSize FlexArray to Zero (or Negative).
Insufficient Memory for Requested ReSize operation.
Attempted to ReSize non-Initialized FlexArray.
Requested FlexArray or ReSize is Too Large.


Attempted PUSH onto Full FlexStack.
Attempted POP or TOP from Empty FlexStack.

{ To be honest, I must add that I may very easily have overlooked something.
If you find such an error, please write and let me know!!! }


Since the only significantly original work in these units is in Unit
GenArray, I have elected not to distribute it in source form. In fact,
the source code for GenArray should be completely unnecessary to the user.
However, if you really want it, you can convince me by sending me a check
for $20.00 at the above address.

As to the FlexPntr unit. ALL the code in it was either directly taken from
an article in PROGRAMMERS JOURNAL by Tom Swann or inspired by the same article
(Programming on the Variant Express PJ V6.5 Sept/Oct 1988), and is of such a
fundamental nature that no changes are really possible or desireable in ANY
context. I have distributed it as a TPU simply because Turbo has no other
method available for PRIVATE declarations (ala ADA). Therefore, since I did
not really originate the code, and since there is no reason to ever change
any of it, I will NOT distribute the source code for any reason. Those
incureably interested individuals should look up the above article, paying
particular attention to Mr. Swann's definitions of IntPtr and IntRec, which
I have renamed "FlexPtr" and "FlxArray" respectively. NOTE: the array which
Mr. Swann defines within the IntRec is referenced with field name "Flex" in
my version of the construct, and is an array of Bytes, not Integers.


 December 22, 2017  Add comments

Leave a Reply