Jean-Pierre Vial wrote:
Le Mardi 2 Septembre 2003 16:38, Silvio a Beccara a écrit :
Hi Frank,
after some time, I spotted the error. It doesn't have anything to do with arrays, but really with a negative sqrt argument in another place of the code, which I hadn't seen before.
I now have another problem: I need to extend the size of a dynamic vector, passed as VAR (i.e. by reference) to a procedure. I need to preserve the elements of the vector to be resized. I use NEW each time inside the procedure, and it works, but this fills up the stack very quickly, and I run out of memory. Do you have any suggestion?
I am not sure that I understand your problem; here is a possible solution to my interpretation of your message (dirty trick, will be hard to maintain in a few months, or by somebody else) 1 make sure that there exists only one thing pointing to your vector in the calling code. Let it be V
2 instead of passing the reference bizarre(var V: ... pass a pointer to it (it will be something much alike a pointer to a pointer) bizarre(addr(V) ... or something like that
3 inside your procedure, create your new vector, copy the relevant part of the old one into the new one, free the old one using the pointer, change V in the calling code so that it points to the new vector
The elements will be transferred from the old vector into the new one, so they are preserved, but the address of V will be changed,
You don't need the "dirty trick" for that. Passing the pointer by reference (`var Foo: BarPtr') will work the same. (That's what reference parameters are for.)
this is why you must be sure that it exists in only one place.
This restriction holds in both cases.
The occupation of the stack will not grow more than needed, but fragmentation may be as much a nuisance as occupation.
Actually, it's the heap (stack can never be fragmented, but you can't create persistent data on it).
Since this way (new, copy, dispose) is a little cumbersome, I've thought about a built-in resize mechanism. However, I see no reasonable way to do it for arbitrary schemata. It would be easy to do with some rather strong restrictions on the structure of the schema, e.g.: The only dependence on the (one) discriminant is the upper bound of an array which is the last field in the schema (which, in fact, is the case almost everywhere in my code where I'd like to have this mechanism). In this case, all that would be required (internally, besides modification of the discriminant) is a `realloc' call. In the worst case, this will do the same as new, copy, dispose, but often it's more efficient (sometimes very much more so, especially with large data structures).
Frank