[Implemented] REDIM and UBOUND
just trying to avoid slipping into obscurity since it was mentioned that it was planned...
Paul Dwyer
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
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?
Code: Select all
PeekL(@Array() - 8)
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"
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"

Paul Dwyer
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
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.Foz wrote:I don't get it, if this codereads the number of elements in an array, how can this not be reliable with large arrays? It's just the count after all.Code: Select all
PeekL(@Array() - 8)
And how large is "large" before this happens?
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.

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.
Re: REDIM and UBOUND
Happy AnniversaryThu 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...

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
Code: Select all
PeekL(@Array() - 8)
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
Paul Dwyer
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
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.
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.
quidquid Latine dictum sit altum videtur
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...
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...