Why can not use _OFFSET type in FOR... NEXT loop?

[Petr]

Why is this bad?

Code: QB64: [Select]

1. DIM m AS _MEM
2. m = _MEMIMAGE(_SCREENIMAGE)
3. DIM clr AS _UNSIGNED LONG, SS AS _OFFSET
4.  
5. DO
6. for ss = m.offset to m.offset +  m.size
7.  
8.  
9. LOOP UNTIL pass
10.  
11.  

is this caused, because internaly is FOR...NEXT pointer defined as smaller data type?

[Raven_Singularity]

I just ran into this issue stepping over image data in RAM.  I'm not sure why _OFFSET variables can't be used as regular integers in FOR loops, but they can't.  Seems convoluted, but oh well.

In your case, set your ss variable to an integer type, such as LONG.  _OFFSET, it seems, is only used to return an offset and doesn't support actually changing the offset value.  Sort of a read only variable type?

[SMcNeill]

ConvertOffset — http://qb64.freeforums.net/thread/52/convert-offset-integer64

That’s all you need, and you’re good to go — both for 64-bit and 32-bit versions.  ;)

[Petr]

Thank you both for your answers. Steve, so I have to say about this be exactly the kind of blindness that one knows, but it doesn't connect.  Your sample program returned me back to reality. Of course! 32bit and 64bit systems! Thank you very much for your function. Maybe you, as a developer, if you wanted to implant it in a new release of QB64, could us get rid of this pain?

[Raven_Singularity]

+1 on automatic conversion of offsets to other integer types in a future QB64 release!

[luke]

Funnily enough many of the limitations on what you can do with an _OFFSET are the intentionally.

When they were first added it was thought they would be strictly for DECLARE LIBRARY and all the casting restrictions are meant to give you a fuzzy feeling of "safety". Of course, this just means we have to find hacks around the safety in even more unsafe ways :)