01-09-2024, 01:11 AM
@bert22306 That's why I keep mentioning that it's probably a good idea for everyone to just get in the habit of always adding a suffix to your &H values.
&HFF&& is 256. Will always be 256. Can't be anything but 256.
&HFFFF&& is 65535. Will always be 65535. Can't be anything but 65535.
Whether we patch the codebase later to mimic QB45 behavior, or not, your results will always remain consistent. If you use it inside VAL, DATA, or just a normal variable calculation, the result will remain consistant. It takes any ambiguity out of the procress and explicitly declares its type. (An integer64 in this case, which would hold all values up to &HFFFFFFFFFFFFFF before going into negative numbers. You can use ~&& for unsigned integer64 values, but I just usually find && to be less stretching of the fingers and easier/quicker typing usually.)
Without those suffix, QB64 has to take it's guess at what you intended. Is &HFF a byte? an unsigned byte? an integer? long? integer64?
QB45 was memory constrained and always tried to store the value in as small of a block as possible. They didn't have a _BYTE variable type, or an _UNSIGNED variable type, so &HFF would fit an INTEGER variable type as 256. &HFFFF also fits an INTEGER as -1. &H10000 is too large for an integer, and as such has to fit in a LONG variable.
Those old rules were designed with the hardware limitations which were commonplace back in the day (640k program size limits, ect). They don't honestly make the most sense in today's programming environment, but if we want to maintain backwards compatibilty, sooner or later we should adddress the issue. When we do, that means &HFFFF would always return -1, rather than the inconsistent -1/65535 which it bounces between now, depending on how/where it's called -- and that might end up breaking folks code which *assumed* the unsuffixed number would always remain signed/unsigned...
...and the best way to protect yourself and your code from that glitch ever affecting you, is to just take the half second to tak on the suffix you need yourself.
&HHFF% <-- integer,so 256
&HFF%% <-- byte, so -1
&HFF~%% <-- unsigned byte, so 255
No ambiguity and it's 100% future proof and will always give you the same result no matter where it's encountered.
Why not use it, once you realize that it may become an issue for you at some point in the future?
&HFF&& is 256. Will always be 256. Can't be anything but 256.
&HFFFF&& is 65535. Will always be 65535. Can't be anything but 65535.
Whether we patch the codebase later to mimic QB45 behavior, or not, your results will always remain consistent. If you use it inside VAL, DATA, or just a normal variable calculation, the result will remain consistant. It takes any ambiguity out of the procress and explicitly declares its type. (An integer64 in this case, which would hold all values up to &HFFFFFFFFFFFFFF before going into negative numbers. You can use ~&& for unsigned integer64 values, but I just usually find && to be less stretching of the fingers and easier/quicker typing usually.)
Without those suffix, QB64 has to take it's guess at what you intended. Is &HFF a byte? an unsigned byte? an integer? long? integer64?
QB45 was memory constrained and always tried to store the value in as small of a block as possible. They didn't have a _BYTE variable type, or an _UNSIGNED variable type, so &HFF would fit an INTEGER variable type as 256. &HFFFF also fits an INTEGER as -1. &H10000 is too large for an integer, and as such has to fit in a LONG variable.
Those old rules were designed with the hardware limitations which were commonplace back in the day (640k program size limits, ect). They don't honestly make the most sense in today's programming environment, but if we want to maintain backwards compatibilty, sooner or later we should adddress the issue. When we do, that means &HFFFF would always return -1, rather than the inconsistent -1/65535 which it bounces between now, depending on how/where it's called -- and that might end up breaking folks code which *assumed* the unsuffixed number would always remain signed/unsigned...
...and the best way to protect yourself and your code from that glitch ever affecting you, is to just take the half second to tak on the suffix you need yourself.
&HHFF% <-- integer,so 256
&HFF%% <-- byte, so -1
&HFF~%% <-- unsigned byte, so 255
No ambiguity and it's 100% future proof and will always give you the same result no matter where it's encountered.
Why not use it, once you realize that it may become an issue for you at some point in the future?