Compiler Bug?
a_riot42
AMX Wizard
Can anyone tell me why the compiler complains that "Case value is not a constant" when the file only contains constants?
Paul
Paul
MODULE_NAME='Switch Case Test'
(***********************************************************)
(* FILE CREATED ON: 07/09/2015 AT: 09:46:02 *)
(***********************************************************)
(***********************************************************)
(***********************************************************)
(* FILE_LAST_MODIFIED_ON: 07/09/2015 AT: 09:57:33 *)
(***********************************************************)
(* System Type : NetLinx *)
(***********************************************************)
(* REV HISTORY: *)
(***********************************************************)
(*
$History: $
*)
(***********************************************************)
(* DEVICE NUMBER DEFINITIONS GO BELOW *)
(***********************************************************)
DEFINE_DEVICE
(***********************************************************)
(* CONSTANT DEFINITIONS GO BELOW *)
(***********************************************************)
DEFINE_CONSTANT
cnCommand1 = 1
cnCommand2 = 2
cnCommand3 = 3
cnCommand4 = 4
cnCommand5 = 5
cnCommand6 = 6
cnCommand7 = 7
cnCommand8 = 8
cnCommand9 = 9
cnCommand10 = 10
char sCmds[10][16] =
{
{'command_1'},
{'command_2'},
{'command_3'},
{'command_4'},
{'command_5'},
{'command_6'},
{'command_7'},
{'command_8'},
{'command_9'},
{'command_10'}
}
(***********************************************************)
(* DATA TYPE DEFINITIONS GO BELOW *)
(***********************************************************)
DEFINE_TYPE
(***********************************************************)
(* VARIABLE DEFINITIONS GO BELOW *)
(***********************************************************)
DEFINE_VARIABLE
(***********************************************************)
(* LATCHING DEFINITIONS GO BELOW *)
(***********************************************************)
DEFINE_LATCHING
(***********************************************************)
(* MUTUALLY EXCLUSIVE DEFINITIONS GO BELOW *)
(***********************************************************)
DEFINE_MUTUALLY_EXCLUSIVE
(***********************************************************)
(* SUBROUTINE/FUNCTION DEFINITIONS GO BELOW *)
(***********************************************************)
(* EXAMPLE: DEFINE_FUNCTION <RETURN_TYPE> <NAME> (<PARAMETERS>) *)
(* EXAMPLE: DEFINE_CALL '<NAME>' (<PARAMETERS>) *)
define_function parseResponse(char sResponse[])
{
stack_var char sCommand[64]
sCommand = remove_string(sResponse, "13,10", 1)
switch(sCommand)
{
case sCmds[cnCommand1]:
{
// Do something
}
}
}
(***********************************************************)
(* STARTUP CODE GOES BELOW *)
(***********************************************************)
DEFINE_START
(***********************************************************)
(* THE EVENTS GO BELOW *)
(***********************************************************)
DEFINE_EVENT
(***********************************************************)
(* THE ACTUAL PROGRAM GOES BELOW *)
(***********************************************************)
DEFINE_PROGRAM
(***********************************************************)
(* END OF PROGRAM *)
(* DO NOT PUT ANY CODE BELOW THIS COMMENT *)
(***********************************************************)
Comments
-
Can anyone tell me why the compiler complains that "Case value is not a constant" when the file only contains constants?help file wrote:The value of the SWITCH expression is tested against each CASE value (a numeric constant or a string literal).
Maybe because it?s an array? An array of constants but it?s still an array. Don?t know for sure but that would be my guess.
This is just another example of why I almost always stick with Select Active unless the Switch Case contains a bunch of Cases with constants (as in 1, 2, 3, etc.) that are in numerical order. In my opinion, there are too many gotchas with Switch Case that makes it just not worth using. Select Active may be a bit more verbose but the flexibility and lack of any type of issues makes it worthwhile in my mind.
-
I've noticed this kind of stuff a lot lately. In general it seems to occur when you use an array in some kind of conditional. for example: I just did project where this would not work.
define_function fn_MyFunction(integer tp_id){ if(Some_Intefger_Arraty[tp_id]){ // if a value in the cell referenced - do something } }
but - do this and it works fine.define_function fn_MyFunction(integer tp_id){ stack_var integer MyValue; MyValue=Some_Intefger_Arrat[tp_id]; if(MyValue){ // if a value in the cell referenced - do something } }
the behavior seemed to be the same when used in the "Switch" of a switch/case or even in the "case"
You might try throwing in a stack_var and transfering the value to it and see if it works.
-
I can work around it easily enough but was curious if there was an error I was making. Silliness.
Paul -
I think in this case it's more an issue being a constant array rather than one of the quirks associated with a switch case since you can't pass a constant to a module but you can if it's an element of a constant array so it's almost like the compiler interprets a constant array element as a variable not a constant.
-
I think in this case it's more an issue being a constant array rather than one of the quirks associated with a switch case since you can't pass a constant to a module but you can if it's an element of a constant array so it's almost like the compiler interprets a constant array element as a variable not a constant.
Then it seems to be there is no such thing as a constant array, although a string is an array of characters which can be a constant so its not consistent. I switched to if-else which should do the same thing without enraging the compiler. Strange that I hadn't come across this before.
Paul
-
Then it seems to be there is no such thing as a constant array, although a string is an array of characters which can be a constant so its not consistent. I switched to if-else which should do the same thing without enraging the compiler. Strange that I hadn't come across this before.
Paul
I wonder if (just for the sheer mindlessness of it) you populated a non-arrayed stack_var just prior to the switch/case if it would work? something like
stack_var char MyString_01[16];
stack_var char MyString_02[16];
stack_var char MyString_03[16];
// etc...
then
MyString_01=sCMDs[01];
MyString_02=sCMDs[02];
MyString_03=sCMDs[03];
// etc..
then
switch(sCommand):{
case MyString_01:{
// do something
}
case MyString_02:{
// do something
}
case MyString_03:{
// do something
// etc.....
-
You can't build case statements around stack_var's - the values need to be constant.
-
You can't build case statements around stack_var's - the values need to be constant.
That's what I thought too. And actually, that's how I've always done it. It was just a thought to see if the whole "Using" and array of constants" could be overcome. -
Yeah, it sucks but switch case statements are handled at compile time as they are generally optimised out to a jump table or something a binary search can be run on.
Interestingly, it looks like the issue here is with the current compiler not acknowledging the array is constant. Regardless of the way the way a constant array is defined (both within define_constant, or in define_variable and prefixed with 'constant') you can write compilable code that assigns a new value to specific indices. This does however throw a runtime error.
Categories
- All Categories
- 2.5K AMX General Discussion
- 922 AMX Technical Discussion
- 514 AMX Hardware
- 502 AMX Control Products
- 3 AMX Video Distribution Products
- 9 AMX Networked AV (SVSI) Products
- AMX Workspace & Collaboration Products
- 3.4K AMX Software
- 151 AMX Resource Management Suite Software
- 386 AMX Design Tools
- 2.4K NetLinx Studio
- 135 Duet/Cafe Duet
- 248 NetLinx Modules & Duet Modules
- 57 AMX RPM Forum
- 228 MODPEDIA - The Public Repository of Modules for Everyone
- 943 AMX Specialty Forums
- 2.6K AMXForums Archive
- 2.6K AMXForums Archive Threads
- 1.5K AMX Hardware
- 432 AMX Applications and Solutions
- 249 Residential Forum
- 182 Tips and Tricks
- 146 AMX Website/Forums
