Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
QB664PE v3.10.0 is now live for X-Mas!!
#38
(12-27-2023, 04:32 PM)mdijkens Wrote:
(12-27-2023, 01:35 PM)RhoSigma Wrote: It's implicit sign extension. If the highest bit in the hex variable is set, one should always EXPLICITLY tell the datatype by using type suffixes. The following works...

Code: (Select All)
CONST const_blue = &HFF0000FF&&
PRINT const_blue, HEX$(const_blue)

and this too...
Code: (Select All)
CONST const_blue = &HFF0000FF~&
PRINT const_blue, HEX$(const_blue)

by the way, 32-bit colors should be unsigned values anyways, it's explicitly mentiond in the wiki in several places regarding image/color usage. Wish people would just once look there befor complaining, its rather sucking to maintain the wiki and knowing nobody use it when needed.
You might be totally right, but it breaks 10 years of QB64 code that always accepted
Code: (Select All)
Const BLUE = &hFF0000FF

Oh, there's no problem accepting the Const BLUE = &HFF0000FF, it always did and will continue to do so, but it can't know what's in the programmers mind. Just by calling your const "BLUE", const can't know it shall be a color value which needs to be treated as unsigned number, for const it's still just some number, only the programmer knows what it is intended for and should code it that way.

All that brings me once again back to RhoSigma's zero'th law of coding:
If you want/need a certain state or behavior, than define it in your code as clear as possible using all capabilities available in the used programming language. Never depend or even worse assume any default behavior.

Unfortunatly many coders do not, cause it offten includes a lot more keypresses, such as using type suffixes, declaring variables, using long unambigious variable names and so on.
Reply


Messages In This Thread
RE: QB664PE v3.10.0 is now live for X-Mas!! - by RhoSigma - 12-27-2023, 05:04 PM



Users browsing this thread: 4 Guest(s)