BUG: Comment being parsed by #define

[monkey0506]

Okay, so we can't have String values implemented as enumerated values, but I've come up with an idea for a workaround...basically it goes like this:

Code: ags

enum LineBreak_Defaults {
  eLineBreak_DefaultDelimiters, // this is for autocompletion, the String value cannot be set here
  // ...
  };

#define eLineBreak_DefaultDelimiters " .,\"'\\})-"  // this is where the value for eLineBreak_DefaultDelimiters is set

If I try to compile, I get the following error:

---------------------------
Compile Error
---------------------------
There was an error compiling your script. The problem was:

In: 'LineBreak'



Error (line 63): Parse error: invalid use of operator '/'



Do you want to fix the script now? (Your game has not been saved).
---------------------------
Yes   No   
---------------------------

So, I try to use a block comment, and get this error:

---------------------------
Compile Error
---------------------------
There was an error compiling your script. The problem was:

In: 'LineBreak'



Error (line 63): Parse error: unexpected operator '*'



Do you want to fix the script now? (Your game has not been saved).
---------------------------
Yes   No   
---------------------------

Shouldn't these be interpreted as comments?

It works fine without the comment on the #define line.

[Gilbert]

I think what #define currently does (don't know about other "real" programming languages) is just to include the content after it (without the space in between) until the end of that line.

So it does nothing but replace the defined text to that string in compile time whenever it appears. So, say:

(a) #define blah hahahaha
(b) #define blah "hahahaha"
(c) #define blah hahahaha;
(d) #define blah hahahaha //mwahaha

when there's a line like:
int blub = blah;

would respectively translated to the following in compile time:
(a) int blub = hahahaha;
(b) int blub = "hahahaha"
(c) int blub = hahahaha;;
(d) int blub = hahahaha //mwahaha




If your really need comments put it above or below the #define lines.

[monkey0506]

Yes, I know how #define-s work, but take the following crappy-generic-made-up-right-now example:

Code: ags

function do_something(String StrParam) {
  /* do something*/
  }

do_something(eLineBreak_Delimiters);

If eLineBreak_Delimiters was #define-d as:

Code: ags

#define eLineBreak_DefaultDelimiters " .,\"'\\})-"  // this is where the value for eLineBreak_DefaultDelimiters is set

Then the line should look like:

Code: ags

do_something(" .,\"'\\})-"  // this is where the value for eLineBreak_DefaultDelimiters is set);

Okay, granted, that would mean the end of the line would be commented out and should generate an error (although...not the one it gave...?).

But if I use a block comment instead, i.e.:

Code: ags

#define eLineBreak_DefaultDelimiters " .,\"'\\})-"  /* this is where the value for eLineBreak_DefaultDelimiters is set*/

Then the line should read as:

Code: ags

do_something(" .,\"'\\})-"  /* this is where the value for eLineBreak_DefaultDelimiters is set */);

Which, albeit bad programming style (IMO), should compile, and should not generate an error.

That's why I started the thread.

[EDIT:]

As an example of "the block comment should work" part, the following line compiles and runs correctly:

Code: ags

Display("SOMETHING!" /* comment! */);

Displaying the line "SOMETHING!" without registering the comment block at all.

Furthermore, yes, putting the comments on a different line is an acceptable, working work-around, however, these errors still shouldn't be generated...(As I mentioned before, yes the regular line comment, in the above example should generate an error, just not the error that it generated )

[Gilbert]

I'd checked it, it's not problem with define I think, if you try stuff like.
#define blah "aaa" /* comment */
and then
Display(blah);
it works, but doing this will generate an error also:
Display(" .,\"'\\})-"Ã,  /* this is where the value for eLineBreak_DefaultDelimiters is set*/);

So it's probably some other glitch in the compiler when interpreting the line, mainly because of the complicated string messing stuff up (removing the block comment works though).

Another thing I noticed, was that if the comments in teh same line were to be included into the #define-d phrase, the script editor should just give the comment part a gray background, not like now which colour the text as if they're real comments.

[monkey0506]

Hmmm...okay then.  I'm not really sure what it is causing the problem...but at least we're agreed that there is a problem.  We...are agreed that there's a problem...right?

Anyway, I think CJ should definitely take a look into this 'cause something is acting a little screwy here.

[Gilbert]

It's probbly those \" \\ etc. causing troubles while the compiler parsed the string.

It's not really common to include comments in #define-d stuff IMO though.

[monkey0506]

Indeed...I didn't think that it did include comments into the #define statement.  But it's reacting strangely.  It probably does have something to do with the \"- and \\-s, but if that's causing problems, it needs to be fixed.  Completely possible to work around it by just not putting comments on the same line...but...at least make it give an appropriate error message! (Just kidding CJ, I know you have a lot on your hands and have been very busy with AGS 2.72 ).  But when you get a chance to fix it, whatever "it" is, I'll appreciate the work.  Just like I appreciate everything you do!

* and...end sucking up to CJ...now *