Variadic Macro Support

Page: 1 2
ID:1516476
 
Mar 12 2014, 11:11 am
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.
Mar 18 2014, 5:07 am
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.
Mar 18 2014, 8:34 am
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).
Mar 18 2014, 9:14 am (Edited on Mar 18 2014, 11:53 am)
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.
Mar 18 2014, 10:23 am
Does any language currently support variable args in preprocessor macros? Last I knew, C++ didn't.
Mar 18 2014, 10:24 am
C99, and C++11.
Jun 8 2016, 3:15 pm
I've put this on my list of possibilities for 511.
Jun 8 2016, 3:46 pm
...I like this news
I don't remember why I liked it, but I like the news
Jun 11 2016, 8:30 am
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.
Jun 11 2016, 9:05 am
#name?
Jul 13 2016, 10:42 am
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.
Jul 14 2016, 7:26 am
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.
Jul 14 2016, 9:38 am
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)
Jul 14 2016, 9:41 am
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)
Jul 14 2016, 9:47 am
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.
Jul 14 2016, 10:04 am
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)
Jul 14 2016, 10:48 am
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.
Jul 14 2016, 11:51 am
Bleh.
Jul 14 2016, 11:56 am
 
#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
Jul 14 2016, 12:12 pm
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