When is "Variable Type" _OFFSET Not an Unsigned Integer?

[Qwerkey]

Steve McNeill has been teaching us _MEM techniques, which I used to a great extent in a recent project.  The use of a _MEM object requires a DIM statement as:

Code: QB64: [Select]

1. DIM CMem AS _MEM, COff AS _OFFSET

with subsequent working code of an image "Image&" as:

Code: QB64: [Select]

1. CMem = _MEMIMAGE(Image&)
2. COff = 0
3. WHILE COff < CMem.SIZE
4.     IF _MEMGET(CMem, CMem.OFFSET + COff + 3, _UNSIGNED _BYTE) < 50 THEN
5.         _MEMPUT CMem, CMem.OFFSET + COff + 3, 0 AS _UNSIGNED _BYTE 'Alpha
6.     ELSE
7.         _MEMPUT CMem, CMem.OFFSET + COff + 3, 120 AS _UNSIGNED _BYTE 'Alpha
8.     END IF
9.     COff = COff + 4
10. WEND
11. _MEMFREE CMem

The variable "COff" indexes along the _MEM block CMem, and is only ever an unsigned integer.  Why, therefore, does it need to be DIMed?  In fact, before I found out from Steve that the DIM COff AS _OFFSET statement was required, I just used the COff as an unsigned integer, and everything worked OK.

I've read all the _OFFSET wiki pages and I'm afraid that didn't help me: the wiki is written for people who actually understand coding!

This is a question from one of the DIM members!

[RhoSigma]

Simply add the _OFFSET type suffix (COff%&), and you don't need to DIM it anymore. DIM specifies a variables type, just as the suffix does. I personally would wish the memblock itself had a defined suffix to get around of ever doing DIM m AS _MEM, but I guess its because internally a memblock is handled like a user TYPE, which can't have a suffix (logic, as each user TYPE is different, but a _MEM block is always same and could get a suffix assigned (maybe in release 1.4?)).

[SMcNeill]

_OFFSETs are basically automatically resizing integers.  On a 32-bit version of QB64, they’re 4 bytes in size and could (almost) be substituted and interchanged for LONG variables.  On a 64-bit version of QB64, _OFFSETs are 8 bytes in size and could (once again, almost) be interchanged with _INTEGER64 variables.

As long as your offset values don’t exceed the limit of your variable type, and you don’t lose precision (like with SINGLE values after a certain point), you can (usually) use any variable type you want in code segments like you provided.

Now, if you noticed, I used *almost* and *usually* several times in those few paragraphs.  That’s because QB64 doesn’t allow us to mix and match integers and offsets very nicely.  You’re very likely to see error messages similar to “cannot convert OFFSET to other variable types”, so most of the time, when you know you need to deal with offsets directly, it’s best to just use offsets completely.

DIM I AS LONG
_MEMPUT M, M.OFFSET + I, ....     

The above has no issues compiling, but try to mix offsets and a FOR loop sometime...

DIM I AS LONG
FOR I = M.OFFSET TO M.OFFSET + M.SIZE

^ The above here is just an error waiting to happen.

[SMcNeill]

Simply add the _OFFSET type suffix (COff%&), and you don't need to DIM it anymore. DIM specifies a variables type, just as the suffix does. I personally would wish the memblock itself had a defined suffix to get around of ever doing DIM m AS _MEM, but I guess its because internally a memblock is handled like a user TYPE, which can't have a suffix (logic, as each user TYPE is different, but a _MEM block is always same and could get a suffix assigned (maybe in release 1.4?)).

We’d talked about making _MEM use an @ suffix, before, in the past, but nobody has implemented it yet.

Instead of DIM M AS _MEM, one could M@...  ;)

[Qwerkey]

Thanks, both.  When composing this post I was saying to myself "I expect that the DIM is required because the computer needs to know how many bytes to attribute to the integer".  So, after all, I had more-or-less understood it.  As I love using variable type suffices, I'll probably use the %& method in future.

Later edit:  Oh, I see that _OFFSET (and _UNSIGNED _OFFSET) are already added to the Variable Types Table in the Wiki.  Some people should spend more time in the Wiki, instead of asking these dumb questions.

[RhoSigma]

We’d talked about making _MEM use an @ suffix, before, in the past, but nobody has implemented it yet.

Instead of DIM M AS _MEM, one could M@...  ;)

That would definitely be a useful and worthwhile extension. I've looked into qb64.bas before to see how type suffixes are handled, but it appears in several places, so it's probably not that easy (as most things when dealing with the qb64 sources). Maybe I find time during the comming holidays to take a closer look.

I was also thinking about an appropriate symbol, and came to the 'µ' to mimic 'mem', but you're right, it should probably be a symbol in the standard ASCII range. As most symbols are already used as suffixes or operators, the '@' seems to be the best alternative for me too.

[FellippeHeitor]

This is such a sensitive area that I hope you guys are extremely careful and thorough in your approaches. Please don’t apply these directly to the repository until thorough testing can be done.

[RhoSigma]

This is such a sensitive area that I hope you guys are extremely careful and thorough in your approaches. Please don’t apply these directly to the repository until thorough testing can be done.

Sure, you can definitely count on that one, I don't want to enter history as the guy who blew up the QB64 project ;)

[SMcNeill]

Sure, you can definitely count on that one, I don't want to enter history as the guy who blew up the QB64 project ;)

I’ve did that before.  Several times, if you remember, from the old [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there] days.  Push a change into the repo that Galleon’s old automated build process didn’t like, and it would fail...  For a few months there, the “dirty” build was broken, from where we’d changed COMMAND$, and Galleon wasn’t around to restart the automated stuff....

I blew up QB64 good that time!  LOL!