&H colors dont work as CONST

[bplus]

Thanks somewhen I learned that suffixes don't mean much for Const and thanks for your fix @RhoSigma.

[Cobalt]

Well Bplus is right, Back in Ver 1.1Build82 you can just do this:
CONST WHITE = &HFFFFFFFF
and you get the correct value, sometime between 1.1 and 1.4 that was changed
Can not find my copies of 1.2 and 1.3 to see what happens there.

As you can see in the attachment, Ver 2.1 prints -1 while Ver 1.1B82 prints the correct value for an _UNSIGNED constant

  [ You are not allowed to view this attachment ]  

[FellippeHeitor]

The whole CONST system was replaced by Steve at some point. We're in internal talks to replace the pre-compiler const evaluator with a runtime evaluator - technically that'd make CONSTs regular variables that have a "can't change" flag. That's in the works, but we don't have a public road map for this specific update yet, so please keep Rho's indications in mind for now.

[SMcNeill]

CONST has always tried to guess as to what type of variable to assign a value to.  Back before I first overhauled CONST to allow us to use more functions with it with the internal math evaluator, it used to shoot for unsigned values by default. 

Try a copy of QB64 around v0.90 or so, and you'll see that &HFFFFFFFF evaluated to -1.

When I overhauled the CONST system to add in our math functions and all, I made a point of trying to switch out to unsigned values, if possible.  &HFFFFFFFF would now become +4286...(whatever).

Under the hood, both these values are the exact same.  One is FFFFFFFF as a signed long, the other is FFFFFFFF as an unsigned long.  The main reason why I chose to swap from signed to unsigned by default, when I overhauled the CONST system the first time, was for numeric matches with POINT.


Now, sometime after the 1.2 and before the 2.1 version which is the most current, I went in and tweaked the CONST system once again.  Before, it ran into issues with explicitly defined types and sometimes ignored them, so I expanded and corrected that issue (along with a few more little things like multiple assignments from the same line).  Since users could now manually define what types they wanted associated with CONST, there wasn't any reason for me to hijack the process and force CONST to choose unsigned values over signed values.  I took that hijack hack out for us as it was no longer necessary.

If one wants to work with unsigned values, simply make certain to assign unsigned values to your const, or else specify the const as being unsigned.

Code: QB64: [Select]

1. Const C = &HFF848888
2. Const C1~& = &HFF848888
3. Const C2 = &HFF848888~&
4. Print C, C1, C2
5.  

-8091512            4286875784          4286875784

C is an signed long.
C1~& is an unsigned long.
C2 is an unsigned long.

Either specify the CONST with an explicit type, or assign the value with the explicit type, and it makes certain that the value is that specific type.  It's only when you leave off an explicit type completely that CONST chooses for itself as to what type of variable works best to store the value for you -- which in the above case happens to be a signed long.   

[SMcNeill]

The issue here doesn't seem to be in CONST.  There actually appears to be some sort of issue with IF which is causing a glitch with this:

Code: QB64: [Select]

1. Const skyC~& = &HFF848888
2. Const skyCompare = &HFF848888~&
3.  
4. Print skyC
5. Print skyCompare
6. If skyC = skyCompare Then Print "They match" Else Print "No match"

From the two print statements, we can see that the two values are exactly the same -- yet the IF statement is showing that they're "No match".  This doesn't appear to be a CONST issue, but an IF issue somewhere.

[FellippeHeitor]

Inspected the C++ output and CONST eval is storing skyC~& as 18446744073701460104 and skyCompare as 4286875784 -- so IF is working as intended.

[SMcNeill]

Inspected the C++ output and CONST eval is storing skyC~& as 18446744073701460104 and skyCompare as 4286875784 -- so IF is working as intended.

I was just looking at that as well.  Things here are complicated as heck.

Code: QB64: [Select]

1. Const skyC~& = &HFF848888
2. Const skyCompare = &HFF848888~&
3. Const skyC2~&& = &HFF848888
4.  
5. Print Hex$(skyC), skyC
6. Print Hex$(skyCompare), skyCompare
7. Print Hex$(skyC2), skyC2
8. If skyC = skyCompare Then Print "They match" Else Print "No match: "

The value we're generating seems to be an unsigned integer 64, rather than an unsigned long.  The odd thing is if you look at the c-c-output for the above.

The first print statement makes certain that we print an unsigned long:

qbs_set(tqbs,qbs_add(qbs_str((uint32)( 18446744073701460104 )),qbs_new_txt(" ")));

The third one, doesn't do that; it makes certain that we print an unsigned integer64:

qbs_set(tqbs,qbs_add(qbs_str((uint64)( 18446744073701460104ull )),qbs_new_txt(" ")));

So the internal value is stored as the same in both cases, and there's some flag which knows to toggle with (unit32) and (uint64) to make certain we have the right value associated with the number.

Except the IF statement doesn't have this explicit assignment associated to it: if ((-( 18446744073701460104 == 4286875784 ))

(There's no uint32 or uint64 in there anywhere, but notice that the ull is missing as well, and that should be what specifies us as an unsigned integer64 -- we should default to an unsigned long here.)


So where's the glitch in this mess?  Apparently the CONST is flagging some sort of internal switch so that PRINT knows to toggle between uint32 and uint64, but exactly what's wrong with the above?  Does IF need this same switch?  Does CONST need something to change?  Why is it sometimes accepting that it's an uint32 and other times ignoring that?

The overall thing has me baffled at the moment.  It doesn't appear that CONST itself is wrong, as the PRINT knows to use uint32 values...  So where exactly is the root of the problem coming from??

[SMcNeill]

Note: Tweaking the IF statement to add the uint32 cast to the values makes things work as expected:

Code: [Select]

if ((-( (uint32)(18446744073701460104) == 4286875784 ))||new_error){
The only issue with this comes from the question:  Is IF the only statement which is missing the (uint32) code, or are there other places where it could be an issue with CONST?  WHY does PRINT have one and make certain to use one, while IF doesn't? 


DO statements are just like IF -- they don't have an explicit (uint32) associated with them either with CONST values.

}while((!(-(*__ULONG_I>= 18446744073701460104 )))&&(!new_error));

That's a little snippet from:
Do
    i = i + 1
    If _KeyHit Then Exit Do
    Print i, skyC
Loop Until i >= skyC

As you can see; there's no (uint32) in there either. 

Print seems to realize that our variable is an unsigned long, but nothing else does...  And I don't have a clue why the heck that is!

[Cobalt]

I don't really care one way or the other, works fine for me now. I just thought I see if Bplus was right about it being different in an earlier version or not. And he was.
AND it turns out Steve is right too! Ver .954(SDL) displays a -1.
Guessing, perhaps, when it switched over to GL it assigned the CONST differently and then an update sometime after 1.1\1.2 changed the way they are allocated.

I say leave them alone. CONSTs are fine just how they are.

[bplus]

I hate to disagree with fellow Ohioan but Const is valuable part of coding in my book. You don't have to use them in your book but to me it is important they work as well as any other coding tool.

It is so much easier to remember and write SkyC than to do &HFFRRGGBB all the time. And what if you want to change that value, you'd have to change it everywhere in your program instead of once in Constants Declares Section.

[_vince]

The whole CONST system was replaced by Steve at some point.

Glad to know the fundamental CONST is in good hands!

May I recommend Steve's useful colour storage tutorial
https://qb64forum.alephc.xyz/index.php?topic=4480.0

though, personally, I prefer to leave it to the pros and just quickly include one of these in my programs ;)
https://qb64.freeforums.net/thread/5/32-bit-color-const-names

[SMcNeill]

though, personally, I prefer to leave it to the pros and just quickly include one of these in my programs ;)
https://qb64.freeforums.net/thread/5/32-bit-color-const-names

@vince With the latest versions of QB64, you can save the includes and just use $COLOR:32 or $COLOR:0.  (Unless you're working with a 256 color screen, in which case you'd probably want the include to set the palette to match the names for any temp/secondary screens you might create.)

[_vince]

oh wow, you built in your colour constants into QB64, handy!

btw, did you hand-pick these constants yourself? I trust that WildWatermelon, BananaMania, VividViolet and such others are tastefully fine tuned to their literal connotation

[SMcNeill]

oh wow, you built in your colour constants into QB64, handy!

btw, did you hand-pick these constants yourself? I trust that WildWatermelon, BananaMania, VividViolet and such others are tastefully fine tuned to their literal connotation

The list came from basically two places:  The first is html standard values used in web browsers everywhere, while the second is from the crayola website and from wiki: https://en.wikipedia.org/wiki/List_of_Crayola_crayon_colors
http://www.jennyscrayoncollection.com/2017/10/complete-list-of-current-crayola-crayon.html
https://www.w3schools.com/colors/colors_names.asp

[Cobalt]

I hate to disagree with fellow Ohioan but Const is valuable part of coding in my book. You don't have to use them in your book but to me it is important they work as well as any other coding tool.

Not sure how to take that.

I didn't mean to suggest that const be mothballed or such. Just that it did not need further disruption, inpart to one of Fellippe's comments earlier.

The whole CONST system was replaced by Steve at some point. We're in internal talks to replace the pre-compiler const evaluator with a runtime evaluator - technically that'd make CONSTs regular variables that have a "can't change" flag. That's in the works, but we don't have a public road map for this specific update yet, so please keep Rho's indications in mind for now.

I would consider myself quite the hypocrite if I said "const's are not important so shove em'" Not sure what I would do without them!
If perhaps you don't like using the affix ~&, it seems to work fine using _RGB32(R,G,B) to assign a color value to a  constant.