ID:139477
 
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?
You have it formatted wrong, I'll help in the morn if no one else replies.
This works:
#define something list
var
something
some_Array[5]

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
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
*/
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.
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
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.
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.
In response to Jp
Ok I see now...