[Oberon] Memory allocation

[Jan Verhoeven]

Hello Jörg

On Sunday 16 January 2011 10:54:26 Jörg Straube wrote:
> Hi
>
> The declaration part of your generic database module could look
> something like this:
>
> MODULE Reflex;
>
> TYPE
>   FieldDesc = RECORD
>     fieldType: INTEGER
>   END;
>   Field* = POINTER TO FieldDesc;
>
>   IntDesc = RECORD (FieldDesc)
>     val*: INTEGER;
>   END;
>   Integer* = POINTER TO IntDesc;
>
>   StrDesc = RECORD (FieldDesc)
>     val*: ARRAY 30 OF CHAR;
>   END;
>   String* = POINTER TO StrDesc;
>
>   Record* = RECORD
>     f*: POINTER TO ARRAY OF Field;
>     listFields*: PROCEDURE();  (* writes all field values to the
> screen *) store*: PROCEDURE()         (* stores the record to a file
> *) END;

The last few years I have some trouble with very abstract thinking, but 
I  had a hunch it would come down to something like this.
Thanks for the help. This gives me a clue how to continue. Much obliged.

>   PROCEDURE NewInt*(i: INTEGER): Integer;
>   PROCEDURE NewStr*(s: ARRAY OF CHAR): String;
>
> END Reflex;
>
> Then if you want to create and initialize a two-field
> record in your code, you would write
>
>   VAR
>     r: Reflex.Record;
>     i: Reflex.Integer;
>     s: Reflex.String;
>   BEGIN
>     NEW(r.f, 2);
>     r.f[0] := Reflex.NewInt(3);           (* r.f[0].val = 3 *)
>     r.f[1] := Reflex.NewStr("Hello");  (* r.f[1].val = "Hello" *)
>     r.listFields();
>     (* the rest of your code *)
>
> If you want to create a 20-field record you would write something
> like
>
>   VAR r: Reflex.Record;
>   BEGIN
>     NEW (r.fields, 20);
>     (* the rest of your code *)
>
>
> br
> Joerg
>
> On 16.01.2011, at 03:28, Jan Verhoeven wrote:
> > Hi Chris,
> >
> > Thanks for your answer.
> >
> > In the late 80's I used Borland's "Reflex" database engine. I have
> > never since seen a better database than Reflex. It could store
> > data, analyze the data and make graphs and tables on the fly.
> >
> > In Reflex I could make a two-field record, but also a 20 field mxed
> > type record. Both records of course have different memory
> > footprints and would need different amounts  of memory to allocate.
> > Inside a record (the structure of which is unknown at compile time
> > of course) there could be integers, formulas and strings in a mixed
> > fashion. So one would need to be able to walk through the fields of
> > the record in a universal way.
> >
> > At the moment, the only way to do such things is by assigning a
> > pointer to byte and 'walking through' the bytes of that record.
> >
> > --
> > Met vriendelijke groeten,
> >
> > Jan Verhoeven
> > http://www.verhoeven272.nl
> >
> > --
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> > systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> systems https://lists.inf.ethz.ch/mailman/listinfo/oberon



-- 
Met vriendelijke groeten,

Jan Verhoeven
http://www.verhoeven272.nl