Le Mercredi 3 Septembre 2003 16:44, Silvio a Beccara a écrit :
Hi everybody,
thanks to the suggestion from Jean-Pierre, Maurice and Frank, after playing around a bit, I figured out how to solve the problem of the resizing of the vectors: basically, I dispose of the copy vectors as soon as they are of no use any longer. With simple cases (where there are only a few calls to the resizing routine) the program works just fine, but look what I get with a "real case" (this is the output of GDB):
Program received signal SIGSEGV, Segmentation fault. Removefrommarklist (Apointer=void) at /home/frank/gpc/gcc-2.95.3/gcc/p/rts/heap.pas:226 226 /home/frank/gpc/gcc-2.95.3/gcc/p/rts/heap.pas: No such file or directory. in /home/frank/gpc/gcc-2.95.3/gcc/p/rts/heap.pas
I don't even know what's going on, can somebody tell me? Is this the kind of problem that Jean-Pierre was referring to?
maybe you could try a variant, especially if you can guess a reasonnable estimate of the maximal size of your vector V.
define two integers as global variables: physicalsize and logicalsize. 1) initialize physicalsize to an estimate of the maximal size of V 2) create V with size physicalsize 3)initialize logicalsize to the true initial value of V (less than physicalsize of course) 4) do whatever you want to do with V , using logicalsize as size of V
when you need to resize, the resize procedure works a bit differently: if the new size is less than physicalsize, resize just updates logicalsize and returns if the new size is greater than physicalsize, increase physicalsize to a much larger value , using the preceeding method: create a new VV with size (the new) physicalsize check that the creation did succeed; if not, abort cleanly copy the relevant datas dispose (or freemem) the old V assign VV to V update logicalsize return (what <<much larger>> means is up to you, the idea is to avoid as much calls to new/dispose or getmem/freemem as possible)
This variant will reduce heap fragmentation, and incidentally it will be faster than the previous one (possibly much faster if resizing is a frequent operation)