#define problem

ID:139477
 
Dec 20 2010, 4:48 am (Edited on Dec 21 2010, 2:59 am)
This complies fine:
var/list/some_Array[5]


But this gives errors:
#define something list
var/something/some_Array[5]

/*
test.dm:2:error: list: undefined var
test.dm:2:error: some_Array: undefined var
*/


Is this a bug, or intended to work like this?
Dec 21 2010, 6:45 pm
You have it formatted wrong, I'll help in the morn if no one else replies.
Dec 21 2010, 6:47 pm
This works:
#define something list
var
    something
        some_Array[5]

Dec 22 2010, 12:10 am
In response to Calus CoRPS
Calus CoRPS wrote:
This works:
#define something list
> var
>   something
>       some_Array[5]


It can be set up dat way, or this way;

#define something list
var/something
  some_array(5)


Cant tab, soz.. So each space represents a tab. :D
Dec 22 2010, 1:43 am
In response to Thelavaking
What about this case then?

#define Vector3 list

mob
    New(Vector3/position)
        x = position[1]
        y = position[2]
        z = position[3]
/*
dfghj.dm:5:error: bad argument definition
*/
Dec 22 2010, 4:30 am (Edited on Dec 22 2010, 4:49 am)
In response to Ripiz
I get the same problem. Seems to occur in the general case:

// 'bar' is some type
#define foo bar

// as part of definition...
...foo/baz


The error appears to be the same message produced as this case:

// 'list': undefined var
// 'test_list': undefined var
var/list /test_list


My guess is that when the macro is inserted an extra space is inserted at the end.

Not sure what workarounds are possible. This works:

#define Vector3 list/position

mob/New(Vector3)
    x = position[1] // etc.


But has obvious drawbacks.

You can use the token-pasting operator:

#define Vector3(x) list/##x

mob/New(Vector3(position))
    world << position


Doesn't look quite right, but better than nothing.

EDIT: I've submitted a bug report http://www.byond.com/members/ DreamMakers?command=add_tracker_issue&tracker=1 . This might be intended behaviour of #define - I suspect they're using a C++ preprocessor (because token-pasting and stringification operators work), and c/c++ are significantly more lax on where whitespace can occur than DM.
Dec 22 2010, 4:52 am
In response to Ripiz
Ripiz wrote:
What about this case then?

> #define Vector3 list
>
> mob
>   New(Vector3/position)
>       x = position[1]
>       y = position[2]
>       z = position[3]
> /*
> dfghj.dm:5:error: bad argument definition
> */
>



Ummm, yeah...

#define Vector3 list

mob
    New(Vector3/position)
        x = position[src.xloc]
        y = position[src.yloc]
        z = position[src.zloc]
/dm>

Or depending what your using it for, Usr.(xyz)loc, or M.(yxz)loc...

--------------------------------------------------

Jp wrote:
> I get the same problem. Seems to occur in the general case:
>
> <dm>
>
> // 'bar' is some type
> #define foo bar
>
> // as part of definition...
> ...foo/baz
>

The error appears to be the same message produced as this case:

> // 'list': undefined var
> // 'test_list': undefined var
> var/list /test_list
>

My guess is that when the macro is inserted an extra space is inserted at the end.

Not sure what workarounds are possible. This works:

> #define Vector3 list/position
>
> mob/New(Vector3)
>     x = position[1] // etc.
>

But has obvious drawbacks.

You can use the token-pasting operator:

> #define Vector3(x) list/##x
>
> mob/New(Vector3(position))
>   world << position
>

Doesn't look quite right, but better than nothing.


Ok for one fixed. You had foo/baz instead of foo/bar..
// 'bar' is some type
#define foo bar

// as part of definition...
...foo/bar


No space should be included...

var/list/test_list
Dec 22 2010, 4:56 am
In response to Thelavaking
Thelavaking wrote:
Ok for one fixed. You had foo/baz instead of foo/bar..
>
> // 'bar' is some type
> #define foo bar
>
> // as part of definition...
> ...foo/bar
>


"baz" was the name of the variable and "foo" was the type. "foo" should be replaced with "bar" to create a variable named "baz" of type /bar.
Dec 22 2010, 4:59 am
In response to Thelavaking
Thelavaking wrote:
Ok for one fixed. You had foo/baz instead of foo/bar..
>
> // 'bar' is some type
> #define foo bar
>
> // as part of definition...
> ...foo/bar
>

No space should be included...

> var/list/test_list
>


You're not following - 'baz' was intentional in the last example, as a stand-in for the variable name. Your 'fix' is the equivalent of this:

var/list/list


which is clearly wrong.

I'm aware no space should be included. My point is that when a macro is expanded a space appears to be appended in the preprocessed code, causing these issues. My guess is this is because Dream Maker has likely repurposed a C++ preprocessor, and C/C++ are distinctly friendlier to having random whitespace in statements than DM is.

My example with the space in it is there because it triggers similar error messages to the case with the macro.

If you don't know what we're talking about, read the reference page on the #define directive.
Dec 22 2010, 1:11 pm
In response to Jp
Ok I see now...