Home AMX User Forum NetLinx Studio
Options

String expression or literal?

PROGRAM_NAME='junk'
DEFINE_CONSTANT
CHAR STR_TEST[]  = 'test';
CHAR TEST_STRING[20] =  "STR_TEST";
If I look at TEST_STRING in a watch window it evaluates as 'STR_TEST'
I have always believed TEST_STRING should equate to 'test'

NetLinx Compile - Version[2.5.2.20]
NI Master Version............: v4.2.379
Enova DGX 8 Version............: v1.6.1.1

Is anybody able to make me understand why this works the way it does?

Comments

  • Options
    ericmedleyericmedley Posts: 4,177
    Take out the double quotes and you will have it.
  • Options
    viningvining Posts: 4,368
    Maybe this will help.

    http://www.amx.com/techsupport/techNote.asp?id=531

    but it doesn't explain why the double quotes around your constant are being evaluated as a literal string. If it's treating it as an expresion then it would be expecting single quotes inside the doubles but nowhere in the tech note does it use doubles in constant declarations, in fact it says not to use them.
  • Options
    mpullinmpullin Posts: 949
    Maybe it makes some kind of a weird exception for constants...
    I, too, would have expected it to evaluate "STR_TEST" as 'test'
  • Options
    HedbergHedberg Posts: 671
    champ wrote: »
    PROGRAM_NAME='junk'
    DEFINE_CONSTANT
    CHAR STR_TEST[]  = 'test';
    CHAR TEST_STRING[20] =  "STR_TEST";
    
    If I look at TEST_STRING in a watch window it evaluates as 'STR_TEST'
    I have always believed TEST_STRING should equate to 'test'

    NetLinx Compile - Version[2.5.2.20]
    NI Master Version............: v4.2.379
    Enova DGX 8 Version............: v1.6.1.1

    Is anybody able to make me understand why this works the way it does?

    You can't reliably use double quote delimited string expressions in either define_constant or define_variable. If you try to do it in define_variable it will throw an error because the RHS is not a constant. In my opinion, it shouldn't compile with the expression in define_constant either. It's not compliant with the rules for string expressions or the syntax rules for the define_constant section and it certainly doesn't produce the desired result.

    Netlinx language seems different than other programming languages in this respect. As I recall, in C, for example, when you properly define a constant all incidences of that constant in the code are replaced with the constant during a pre-compile phase. Not so in Netlinx, it seems.

    This "feature" has been discussed before:
    http://www.amxforums.com/showthread.php?1357-Define_constant-Char
  • Options
    champchamp Posts: 261
    Thanks for the tech note link vining, Netlinx is pretty inconsistent with string declarations so it is easy to mess it up if you haven't done it in a while.
    ericmedley wrote: »
    Take out the double quotes and you will have it.
    PROGRAM_NAME='junk'
    DEFINE_CONSTANT
    CHAR STR_TEST[]  = 'test';
    CHAR TEST_STRING[] = STR_TEST;
    
    I tried that first but not having the double quotes makes TEST_STRING have a length of 1 and a value of 0.

    My production code has a 2D array of strings, I wanted to be able to refer to..
    DEFINE_CONSTANT
    CHAR STR_CONNECTED[] = 'Connected';
    CHAR STR_NOT_CONNECTED[] = 'Disconnected';
    CHAR BOOL_STRING[2][20]	= { "STR_NOT_CONNECTED", "STR_CONNECTED" };	// this evaluates as { 'STR_NOT_CONNECTED', 'STR_CONNECTED' }
    
    I'm referring to STR_CONNECTED and BOOL_STRING[2] in different parts of code and didn't want to screw up if I decide to change the wording of STR_CONNECTED to something like 'unplugged' and forgot to change BOOL_STRING[2].

    I chose to change the code to index BOOL_STRING whenever I want the string, it is messier in code but it works.
    CHAR IDX_NOT_CONNECTED = 1; // index of BOOL_STRING	
    CHAR IDX_CONNECTED= 2; // index of BOOL_STRING
    CHAR BOOL_STRING[2][MAX_STRING_SIZE]	= { 'Disconnected','Connected' };	// Front panel lockout values
    
    My other option would have been to make BOOL_STRING a variable but I didn't want to do that.
  • Options
    mpullinmpullin Posts: 949
    I think what you ended up doing is more elegant than what you wanted to do. You have all the strings in one place now. Plus, there's fewer variables, since with the first method you'd need to have indices somewhere anyway.
Sign In or Register to comment.