ID:1516476
 
Resolved
Variadic #define macros are now supported. For example:

#define dostuff(a,b...) a.myproc(b)

Preceding the variadic argument with ## in the replacement expression will trim off any preceding commas if the argument is empty.
Applies to:DM Language
Status: Resolved (511.1348)

This issue has been resolved.
I think it would be nice to have support for a variable number of arguments for preprocessor macros.

As far as I know, the number of macro arguments is currently restricted to those in the definition, and there is no way around this. This makes macros that much more inflexible when compared to real procs.

It would probably make sense to use the same syntax supported by many C compilers with an ellipsis (...) and a __VA_ARGS__ identifier. However, if a better, unique solution can be found for DM that would also work too.

I just tend to encounter situations where a macro could be used to replace a relatively simple proc, and thereby avoid the overhead of an actual call. However, there is sometimes the problem of optional or variable arguments, which cannot be solved using macros as they currently are.

Hopefully this makes sense. This certainly wouldn't be a very high priority feature, since most developers probably wouldn't use it, but I just wanted to suggest the idea.
What do you mean? How would you be using a macro to perform some actions the same as with calling a proc (? ...you are calling a proc though..? so it's the same?) without an overhead or w/e it is you're saying.

At the moment, i'm not following.
Well the macro is expanded at compile-time, so it's not a procedure call, it's more a copy/paste of literal code into all the places where the macro is used.

Where-as a procedure call says "call this code" and the expansion happens at runtime. The benefit being you don't massively bloat the DMB with duplicate instructions, general maintainability etc (tracking runtimes inside macro functions isn't the most pleasant thing).
Oh. My bad, i missed him saying preprocessor macros.. i was thinking about it completely differently, in that case.. yeah i get this then :D.
I was wondering, when reading through your explanation, at it sounding like the preprocessor directives stuffs, so that makes sense now, thanks.
Does any language currently support variable args in preprocessor macros? Last I knew, C++ didn't.
C99, and C++11.
I've put this on my list of possibilities for 511.
...I like this news
I don't remember why I liked it, but I like the news
I ended up creating a macro monstrosity with an undocumented C-replicating feature with macros, it'd be nice if the #name feature was documented and any quirks it might have.
#name?
Lummox JR resolved issue with message:
Variadic #define macros are now supported. For example:

#define dostuff(a,b...) a.myproc(b)

Preceding the variadic argument with ## in the replacement expression will trim off any preceding commas if the argument is empty.
Can you show an example of this in use? No luck in trying to get it to compile. What I've tried:

#define somedefine(##a, ##b) ...
##define somedefine(a, b) ...


Must be misunderstanding something.
The ## goes in the replacement expression, and only if you want to trim any preceding commas away when the variadic arg is empty. For instance:

#define AddMe(list,items...) list.Add(src,##items)
In response to Lummox JR
So this would compile?

// Assume somedefine does some stuff based on a, b, c
#define somedefine(a, b, c) ...

// ...

somedefine(a)
In response to FKI
FKI wrote:
So this would compile?

// Assume somedefine does some stuff based on a, b, c
#define somedefine(a, b, c) ...

// ...

somedefine(a)

No. In a variadic macro, the last argument has to end in ... and that signals the compiler to treat it differently. In your case, if you want a macro that can take one or more arguments, then your first argument would be normal and the second would end in ... so it would be optional.
Hm, so why does the first line compile when it should be the second line?

#define _heavy_stunned(character, cause, causer...) (((cause && character:heavy_stun_cause != cause) || (causer && character:heavy_stun_causer != causer)) ? 0 : 1)
#define _heavy_stunned(character, cause, causer...) (((##cause && character:heavy_stun_cause != ##cause) || (##causer && character:heavy_stun_causer != ##causer)) ? 0 : 1)
I don't know, but you're using ## entirely wrong here. There's nowhere in that replacement expression that you'd need to trim out a preceding comma, so don't use ## there.
Bleh.
#define dostuff(a,b,c...) a.some_proc(b,##c)

mob
Login()
dostuff(src,"Hello, World!"," derp")
proc
some_proc(s1,s2)
world << s1+s2
In response to Kozuma3
So what's the point in your usage of ## there? What's its significance and why couldn't you just leave it out?

Edit: Ok, maybe it's because argument c being optional, there's a possibility of there being a comma at the end for no reason? So using ## is a "just in case" type of thing?

Page: 1 2