Board index » delphi » Remove items from arr

Remove items from arr

-=[ In:b...@waterw.com was heard to say... ]=-

 In> Ran into a problem with memory recently with a huge array I'm
 In> using in my file manager.  This occurs while weeding out files that
 In> don't exist.  What I'm doing is reading in filenames from a
 In> descript.ion into one array, creating another, and going through each
 In> item.  If that item's filename exists, I put it into the second array.
 In> This has worked up to now.  Is there a way to "weed" out the
 In> non-existant files without creating the second array?
 In> This is the setup I'm currently using, if it helps.

 [ code snipped ]

You'd be better off using a structure such as the one below, which will be
easier to manage for your purposes. I've added a boolean field, which will
save the need for a second array when checking for the existence of the
actual file. Just initialize Found to false when you read the data from
the DESCRIPT.ION file into the array, and then when you've loaded all the
data you can use your file_exist() function to set Found to true if the
actual file is in the directory. Also, make Numfiles an independent variable,
and increment it as you read the DESCRIPT.ION file data, then in weedfiles()
you can get rid of all those counter variables and just use a FOR/DO loop to
traverse your loaded array, checking for each file and setting the Found
field as you go.

type
   recType2 = record
      List : string[12];
      Size : string[15];
      Desc : string[desclen];
      Mem  : string[4]];
      Found: boolean;
   end;
   tArray = array[1..maxfiles] of ^recType2;
   recArray = ^tArray;

var
   Numfiles: word;

procedure weedfiles(var rec: tArray);
var
   i:integer;

begin
   for i := 1 to Numfiles do begin
      if (file_exists(rec^[i]^.list)) and (rec^[i]^.list[2] <> ':') then
         rec^[i]^.Found := true;
      writeln('rec^[',i,']^.list := ',rec^[i]^.list);
   end;
end;

Pardon my extensive rewrite of your code, but I wanted you to see how much
simpler your code would become. I've included a LoadArray procedure below to
give you an idea how to load the improvised data structure.

procedure LoadArray(var rec: tArray);
begin
   New(rec);
   Numfiles := 0;
   while not Eof(DescFile) do begin
      Inc(Numfiles);
      GetMem(rec^[Numfiles],SizeOf(recType2));
      with rec^[Nmfiles]^ do begin
         { read in the file data }
         ...
         Found := False;
      end;
   end;
end;

        -- Kim Forwood --

  /-=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=-\
  $           Kim Forwood  <kim.forw...@access.cn.camriv.bc.ca>          %
  %         For what purpose is life, if one cannot live freely?         $
  \-=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=-/

___ Blue Wave/QWK v2.20

 

Re:Remove items from arr


-=[ In:b...@waterw.com was heard to say... ]=-

 In> Well, thanks to all of you have have sent me your help and source.
 In> I decided to change the entire structure into a Linked list (more of a
 In> learning project).  Ben outlined this nicely for me, in a way that
 In> even a newbie like me could understand :>
 In> The problem is that I have implemented all the linked list changes
 In> to all my units, but when I compile I get a Compiler error 49 - Data
 In> Segment too large.  Which is ironic, since it suggests that I use
 In> pointers (which led to the error)

Um... If you're using a linked list, you're using pointers. Also, I don't
see why you think error 49 suggests you're using pointers... if anything it
would suggest that you're NOT using them.

 In> I have tried streamlining all global variables, to no avail.  The
 In> header of the main file (which just has the lightbar and menu
 In> routines) is:

 In> Program VGBMan;
 In> {$A-,B-,D+,E-,F+,G-,I+,L+,N-,O+,P-,Q-,R+,S+,T+,V-,X+,Y-}
 In> {$M 65520,0,70000}
 In> Uses
 In> Overlay,ovrumb,initer,Crt,Dos,qb,beb,vgbtpu,shadow,cheat,mouse,color,li
 In> nk; {$O Dos}
 In> {$O qb}
 In> {$O beb}
 In> {$O vgbtpu}
 In> {$O cheat}
 In> {$O color}
 In> {$O link}

 In> Any suggestions on what I can do?  All the units compile ok, just
 In> the main one bombs out with this error.

The above doesn't really show us much, but one thing that looks like it
will cause problems when you're using pointers in large structures is your
maximum heap, which is only 70k. That isn't much to work with and unless
you're calling an external program at some point that needs the other 570k,
you should increase it as much as possible.

        -- Kim Forwood --

  /-=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=-\
  $           Kim Forwood  <kim.forw...@access.cn.camriv.bc.ca>          %
  %         For what purpose is life, if one cannot live freely?         $
  \-=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=-/

___ Blue Wave/QWK v2.20

Re:Remove items from arr


-=[ In:b...@waterw.com was heard to say... ]=-

 In> Now .. the only thing left is to debug the new changes I put in
 In> before the memory problems :>
 In> Which leads me to this, it exec()'s to call unzip.exe, but now,
 In> memavail tells me I have 0 bytes free, and I have no more major
 In> records to convert to pointers, and right at the point where all I
 In> need is just a little boost .. hrmm, maybe changing all my vars to
 In> pointers ... I'll play around with it some more.

The more you use pointers, the more heap memory you use, and the less there
is for loading the external program. So changing your variables to pointers
will not be any help in itself. From your original post you showed that you
had the {$M} compiler directive set to only allow 70k of heap... You need to
increase that for your pointer variables, but at the same time reserve enough
for the external program so that it can be loaded into memory when you call
Exec(). If you're calling PKUNZIP.EXE, you'll need to reserve approx. 250 to
300k for it, if I recall correctly.

You should get your hands on one of several memory swapping units that are
available (I use EXECWSWP), and by using them you can keep your maximum heap
higher than you normally could, and still be able to run external programs
by swapping your parent program to disk or EMS/XMS.

        -- Kim Forwood --

  /-=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=-\
  $           Kim Forwood  <kim.forw...@access.cn.camriv.bc.ca>          %
  %         For what purpose is life, if one cannot live freely?         $
  \-=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=-/

___ Blue Wave/QWK v2.20

Other Threads