feature request: __ARGS__ for logging (cf __FILE__, __LINE__, __FUNC___)

[Jacob Carlborg]

On 2013-02-01 11:34, timotheecour wrote:
> One of the rare features I miss in C/C++ is stringification macro using
> "#x":
>
> ---
> #include ...
> #define DEBUG(x) disp_val(#x,x)
> template<typename T>
> void disp_val(const char*name, const T& x) {std::cout << name << "=" << x;}
> int main(){
> DEBUG(1+2); //will print 1+2=3 (and we can add line, file and func info)
> ASSERT(1+2==4); //can also be defined such that it'll print 1+2==4
> failed...
> }
> ---
>
> In D, we have built-in assert message that'll print the failing
> expression "1+2==4 failed" in case of failure but that's about it: no
> further processing can be done on that message, and there's nothing we
> can do about the DEBUG(1+2) case. I did a function that requires one to
> write mixin(myDebug("1+2")); but that's not as good, especially because
> of the quoting that makes most IDE's unaware of the syntax inside (maybe
> monod would work but still...).
>
> However there could be a clean D solution that alleviates need for macros:
> I'd like to add __ARGS__ to the list of __FILE__, __LINE__, __FUNC___:
>
> P1) 1st proposal:
> __ARGS__ is a string representing the comma separated list of arguments
> passed:
> void DEBUG(T,A)(T a, A args=__ARGS__){writeln(args,"=",a);}
> void DEBUG2(T1,T2,A)(T1 a1,T2 a2, A args=__ARGS__){writeln(args);}
> DEBUG(1+ 2); //will print "1+ 2=3", ie args="1+ 2"
> DEBUG(1+ 2,
> 3*3);
> //will print "1+ 2,3*3" (ie normalize the comma separation)
>
> P2) same but __ARGS__ is string[] with one string per argument; the
> compiler already did the job of parsing, might as well use it:
>
> void DEBUG(T)(T a1, T a2, string[] args=__ARGS__){
> writeln(args[0],"=",a1);
> writeln(args[1],"=",a2);
> }
>
> A question: whether or not to include the first argument in a
> UFCS/member function call ("hello".fun(1+2) ).
>
> P3)
> additionally, create a __CONTEXT__ that is a struct consisting of
> __ARGS__,__FILE__, __LINE__, __FUNC___. This has been proposed before
> and makes even more sense now. Additionally, it could give info on
> whether the call was UFCS'd or not, etc, information which is lost
> otherwise (I don't think traits could help distinguish which version was
> called, a.fun(b) or fun(a,b)).

Sounds like an ugly hack for AST macros. This is a proposal for AST 
macros I've been working on. It's not finished but here it is:

https://dl.dropbox.com/u/18386187/ast_macros.html

-- 
/Jacob Carlborg