REDIM Arrays

[John]

I noticed a post on Richard's BBC4W forum about REDIMing an array to a smaller size. I think this topic also has merit when talking about string management. In SB this isn't an issue as arrays are linked lists of dynamic / typeless data. This doesn't come without a price, (performance) but for most applications (not array based graphics / math) this works out fine. I detest having to manage garbage.

It's complicated. Imagine a scenario in which an array is gradually shrunk in size, in a series of steps, by calling PROCredimpreserve. The first call is guaranteed to increase overall memory usage, because the original array on the heap is leaked. The second call is also guaranteed to increase, not reduce, memory usage because in order to 'preserve' the contents of the array a new block of memory must be allocated first, and the contents of the old block copied into it.

On the third and subsequent calls to PROCredimpreserve it is impossible to say what will happen to overall memory usage because it depends on implementation detail of the Windows heap manager. In principle the 'new', smaller, array may be allocated from memory which was 'freed' during a previous call, but Windows may choose not to do that, for example if it could result in excessive heap fragmentation.

What one can say for certain is that, in the above scenario, the strategy which will use the least amount of overall memory is not to call PROCredimpreserve at all, but simply to shrink the array 'in place', i.e. on the heap where it was originally allocated!

Richard.

[Mike Lobanovsky]

On the third and subsequent calls to PROCredimpreserve it is impossible to say what will happen to overall memory usage...

The following is a likely answer by an enlightened user:

Despite all the verbosity, this isn't a Windows drawback. This is a language author's direct neglect or indifference to rely on a multi-purpose memory allocator in language-specific and not-so-uncommon cases of legit ReDim Preserve in user code. Either ban it in your language altogether or be so kind as to spend another two weeks of your precious time to provide your own dedicated and fool-proof memory allocator. And don't forget about Size of Stack Reserve too for the benefit of those who would prefer to see usable recursion in their code.

Just saying tho.

[John]

I think the issue of memory management is paramount to any BASIC language. At this point Peter Verhas's MyAlloc (what is used in SB) offers the best all around solution. I'm open to all suggestions including wrapping C++.

[Mike Lobanovsky]

My previous message was somewhat hasty. Now that I've read their forum thread, I see it regards a user-coded ReDim Preserve implementation. Why would anyone code their own one? Evidently BBC4W doesn't offer it out-of-the-box?

It's tremendously difficult to implement a non-leaking all-in-one ReDim Preserve for strings using multi-purpose kernel allocators of all sorts or C-language malloc/calloc/realloc only. If I were the language author, I would be addressing this issue within the scope of the language's managed memory pool and an associated garbage collector in order to discourage the users trying to re-invent the wheel using questionable means at hand.

Discouragement is what Richard is obviously trying to convey. But does BBC4W offer anything better instead?

[John]

Richard seems set in his ways and that's fine if it works for him. BBC4W seems like an implant in Windows. (only way I can think to describe it)