PureBasic Forums - English

just trying to avoid slipping into obscurity since it was mentioned that it was planned...

There is a ubound macro somewhere in this forum, but it's NOT reliable/working with big arrays.
So a native command (that works all the time) would be the best.

BTW:
Post subject: REDIM and UBOUND
Posted: Thu May 15, 2003 09:41

We will have the 5 year anniversary pretty soon

sorry guys, i lost this wish in the wii match with fred.

I don't get it, if this code reads the number of elements in an array, how can this not be reliable with large arrays? It's just the count after all.

And how large is "large" before this happens?

Foz,

Is that official? ie OK via the PB team? "supported" I guess you'd say. It sounds like the kind of workaround that comes back and bites you next version.

If so, then change the wishlist item to "please add that to the docs for the next version"

Foz wrote:I don't get it, if this code

Code: Select all

PeekL(@Array() - 8)

reads the number of elements in an array, how can this not be reliable with large arrays? It's just the count after all.

And how large is "large" before this happens?

The only thing I can say (from experience) is that I used the ubound macro a lot in the oop preprocessor that I coded several years ago, and while adding more capabilities to the source code the preprocessor stopped working right.
After disabling the ubound macro and using a different technique to store the size of an array the preprocessor code worked again.
After that I tested and tested and tested to verify my findings.

The conclusion was that depending on the size of the parsed oop code the preprocessor stopped working.

The needed size of the array that is needed to make the ubound macro fail escapes my mind because it was many many moons ago.

bye
fsw

EDIT: thinking of it, the culprit could also have been a bug with macros in the PureBasic compiler. But this is something only the PureBasic development team could answer.

From what I understand (which isn't much, admittedly ), just before the array pointer, there are two Longs (8 bytes - which is why you minus 8 from the Array pointer).

The first long is the current number of elements.
- Note that this is a SIGNED long, so the maximum value stored is 2,147,483,647.
- Also, to get the UBound, (the number of the last element) you will have to -1 from the count.
- If you are running a 32 bit OS, then you are going to hit memory problems before you fill all the elements. It has been discussed in other parts of the forum where 1.7gb is the real hard limit given by Windows (an array of byte was used to find the limit.)
- Finally, more as a reminder for me if I end up hunting for this information again in 6 months or so (and I will), if you are going to declare the maximum array size, it is the maximum long minus 1, because PB declares one extra array slot (if you Dim a.l(10), you have 11 elements, from 0 to 10)

The second long is the type, i.e. Long, Byte, etc

Now this does seem clean and efficient to me, so I can't see the PB Team changing it any time soon. However I would use a macro or procedure in a common helper included file, so if they do make changes at a later date it's much easier to change one place than attempting to hunt down all the instances where you've hard coded it.

Also, with such information, I cannot see why it would become unstable with large numbers, unless you went past the maximum Long size.

Perhaps the PB team could chime in about now....

Thu May 15, 2003 09:41 - fsw wrote:I know working on the core language is not that fun as - let's say... on the 3D stuff.

But I would love to see these commands build in the core language...

Happy Anniversary

This thread is the same age as my son!

so what ?

So it would make me very happy if you could read the thread and reply to the outstanding question about whether
is a safe thing to use in our code or if the ReDim request is a legitimate one and if so, could it be included in the PB product

Thanks

ReDim has been there since 4.00.

Seriously, if you can't even read the manual before (re-)requesting something that already exists, how can you expect us to actually spend
the time to implement such requests ?

About the PeekL() thing:
It has been like this for quite a while and probably won't change soon, but i can not give you any guarantees on that.

Whats so wrong with simply sticking the array size into a variable?
After all its you who Dim'ed the array, so you should know how big it is.

I'd rather implement new functions that actually tell you something you don't already know.

Filling in arrays dynamically causes the need for it.

In fact you recognise that need with Linked Lists as you provide a function for it with CountList(), all we are asking for is CountArray() to go with that.

Sure we could have variable that we keep a track of, but then the same could be said for linked lists...

This is planned for a future version.