www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - __FUNCTION__ implemented with mixins and mangles

reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
It's not foolproof, but I found it useful enough; maybe others will too.

// Parsing mangles for fun and profit.
char[] _getJustName(char[] mangle)
{
    size_t idx = 1;
    size_t start = idx;
    size_t len = 0;

    while(idx < mangle.length && mangle[idx] >= '0' &&
          mangle[idx] <= '9')
    {
        int size = mangle[idx++] - '0';

        while(mangle[idx] >= '0' && mangle[idx] <= '9')
            size = (size * 10) + (mangle[idx++] - '0');

        start = idx;
        len = size;
        idx += size;
    }

    if(start < mangle.length)
        return mangle[start .. start + len];
    else
        return "";
}

// Eheheh, I has a __FUNCTION__.
const char[] FuncNameMix = "static if(!is(typeof(__FUNCTION__)))"
"{ struct __FUNCTION {} const char[] __FUNCTION__ ="
"_getJustName(__FUNCTION.mangleof); }";

To use, just mix into any function where you want to use __FUNCTION__,
and it'll be declared as a const char[].

void forble()
{
    mixin(FuncNameMix);
    pragma(msg, __FUNCTION__); // shows "forble"
}

It doesn't seem to cause any noticeable bloat.  The only reference I
found to __FUNCTION in an executable compiled with -release was the
contents of the FuncNameMix constant itself; I'm sure an "enum string"
in D2 wouldn't be emitted like this.

It doesn't work for nested functions, but that's just a little more
parsing work.  If you want a version that displays the FQN instead of
just the function name, I have that too.

For those wondering how this works, it's pretty simple: when you
declare a type within a function, its mangleof contains the function's
name.  All the mixin is doing is declaring a type within the function
(struct __FUNCTION), then parsing the owning function's name out of
the type's mangleof.
Jun 12 2009
next sibling parent davidl <davidl nospam.org> writes:
在 Sat, 13 Jun 2009 00:40:09 +0800,Jarrett Billingsley  
<jarrett.billingsley gmail.com> 写道:

 It's not foolproof, but I found it useful enough; maybe others will too.

 // Parsing mangles for fun and profit.
 char[] _getJustName(char[] mangle)
 {
     size_t idx = 1;
     size_t start = idx;
     size_t len = 0;

     while(idx < mangle.length && mangle[idx] >= '0' &&
           mangle[idx] <= '9')
     {
         int size = mangle[idx++] - '0';

         while(mangle[idx] >= '0' && mangle[idx] <= '9')
             size = (size * 10) + (mangle[idx++] - '0');

         start = idx;
         len = size;
         idx += size;
     }

     if(start < mangle.length)
         return mangle[start .. start + len];
     else
         return "";
 }

 // Eheheh, I has a __FUNCTION__.
 const char[] FuncNameMix = "static if(!is(typeof(__FUNCTION__)))"
 "{ struct __FUNCTION {} const char[] __FUNCTION__ ="
 "_getJustName(__FUNCTION.mangleof); }";

 To use, just mix into any function where you want to use __FUNCTION__,
 and it'll be declared as a const char[].

 void forble()
 {
     mixin(FuncNameMix);
     pragma(msg, __FUNCTION__); // shows "forble"
 }

 It doesn't seem to cause any noticeable bloat.  The only reference I
 found to __FUNCTION in an executable compiled with -release was the
 contents of the FuncNameMix constant itself; I'm sure an "enum string"
 in D2 wouldn't be emitted like this.

 It doesn't work for nested functions, but that's just a little more
 parsing work.  If you want a version that displays the FQN instead of
 just the function name, I have that too.

 For those wondering how this works, it's pretty simple: when you
 declare a type within a function, its mangleof contains the function's
 name.  All the mixin is doing is declaring a type within the function
 (struct __FUNCTION), then parsing the owning function's name out of
 the type's mangleof.

Cool! But basing on mangled name might be broken in the future release of DMD. -- 使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
Jun 12 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
2009/6/12 davidl <davidl nospam.org>:
 $B:_(B Sat, 13 Jun 2009 00:40:09 +0800$B!$(BJarrett Billingsley
 <jarrett.billingsley gmail.com> $B<LF;(B:

 It's not foolproof, but I found it useful enough; maybe others will too.

 // Parsing mangles for fun and profit.
 char[] _getJustName(char[] mangle)
 {
    size_t idx = 1;
    size_t start = idx;
    size_t len = 0;

    while(idx < mangle.length && mangle[idx] >= '0' &&
          mangle[idx] <= '9')
    {
        int size = mangle[idx++] - '0';

        while(mangle[idx] >= '0' && mangle[idx] <= '9')
            size = (size * 10) + (mangle[idx++] - '0');

        start = idx;
        len = size;
        idx += size;
    }

    if(start < mangle.length)
        return mangle[start .. start + len];
    else
        return "";
 }

 // Eheheh, I has a __FUNCTION__.
 const char[] FuncNameMix = "static if(!is(typeof(__FUNCTION__)))"
 "{ struct __FUNCTION {} const char[] __FUNCTION__ ="
 "_getJustName(__FUNCTION.mangleof); }";

 To use, just mix into any function where you want to use __FUNCTION__,
 and it'll be declared as a const char[].

 void forble()
 {
    mixin(FuncNameMix);
    pragma(msg, __FUNCTION__); // shows "forble"
 }

 It doesn't seem to cause any noticeable bloat.  The only reference I
 found to __FUNCTION in an executable compiled with -release was the
 contents of the FuncNameMix constant itself; I'm sure an "enum string"
 in D2 wouldn't be emitted like this.

 It doesn't work for nested functions, but that's just a little more
 parsing work.  If you want a version that displays the FQN instead of
 just the function name, I have that too.

 For those wondering how this works, it's pretty simple: when you
 declare a type within a function, its mangleof contains the function's
 name.  All the mixin is doing is declaring a type within the function
 (struct __FUNCTION), then parsing the owning function's name out of
 the type's mangleof.

Cool! But basing on mangled name might be broken in the future release of DMD.

Only if DMD is generating incorrect mangles now. Mangles are in the spec; parsing them is completely valid, cross-platform and cross-compiler.
Jun 12 2009
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Jarrett Billingsley wrote:
 It's not foolproof, but I found it useful enough; maybe others will too.
 
 // Parsing mangles for fun and profit.
 char[] _getJustName(char[] mangle)
 {
     size_t idx = 1;
     size_t start = idx;
     size_t len = 0;
 
     while(idx < mangle.length && mangle[idx] >= '0' &&
           mangle[idx] <= '9')
     {
         int size = mangle[idx++] - '0';
 
         while(mangle[idx] >= '0' && mangle[idx] <= '9')
             size = (size * 10) + (mangle[idx++] - '0');
 
         start = idx;
         len = size;
         idx += size;
     }
 
     if(start < mangle.length)
         return mangle[start .. start + len];
     else
         return "";
 }
 
 // Eheheh, I has a __FUNCTION__.
 const char[] FuncNameMix = "static if(!is(typeof(__FUNCTION__)))"
 "{ struct __FUNCTION {} const char[] __FUNCTION__ ="
 "_getJustName(__FUNCTION.mangleof); }";
 
 To use, just mix into any function where you want to use __FUNCTION__,
 and it'll be declared as a const char[].
 
 void forble()
 {
     mixin(FuncNameMix);
     pragma(msg, __FUNCTION__); // shows "forble"
 }
 
 It doesn't seem to cause any noticeable bloat.  The only reference I
 found to __FUNCTION in an executable compiled with -release was the
 contents of the FuncNameMix constant itself; I'm sure an "enum string"
 in D2 wouldn't be emitted like this.
 
 It doesn't work for nested functions, but that's just a little more
 parsing work.  If you want a version that displays the FQN instead of
 just the function name, I have that too.
 
 For those wondering how this works, it's pretty simple: when you
 declare a type within a function, its mangleof contains the function's
 name.  All the mixin is doing is declaring a type within the function
 (struct __FUNCTION), then parsing the owning function's name out of
 the type's mangleof.

Awesome, thanks!
Jun 12 2009
prev sibling next sibling parent reply zsxxsz <zhengshuxin hexun.com> writes:
It's good. But I think it should be implement by the DMD compiler, just like
__FILE__  and __LINE__. __FUNCTION__ should be the base D language syntax same
as
__FILE__, __LINE__, in C99, they're all the compiler's things to get these and
the
compiler do these more easily than any library.
Jun 13 2009
next sibling parent reply grauzone <none example.net> writes:
Jarrett Billingsley wrote:
 On Sat, Jun 13, 2009 at 9:46 PM, zsxxsz<zhengshuxin hexun.com> wrote:
 It's good. But I think it should be implement by the DMD compiler, just like
 __FILE__  and __LINE__. __FUNCTION__ should be the base D language syntax same
as
 __FILE__, __LINE__, in C99, they're all the compiler's things to get these and
the
 compiler do these more easily than any library.

I completely agree, but Walter and Andrei's argument against it is - where does it end? Do we need __PACKAGE__, __MODULE__, __TYPE__, __TEMPLATE__, etc. etc. etc.? And I agree with them too - but you

All we need is a __HERE__, which expands into a struct literal that provides module, filename, etc. fields. It even can be linked to the next enclosing scope to walk upwards nested functions and types. __FILE__ becomes __HERE__.filename, __LINE__ becomes __HERE__.line
 know, it'd be nice to actually get some results on these things once
 in a while instead of a bunch of bullshit bikeshed discussions.
 Sheesh.

Jun 14 2009
parent grauzone <none example.net> writes:
Jarrett Billingsley wrote:
 On Sun, Jun 14, 2009 at 9:31 AM, Denis Koroskin<2korden gmail.com> wrote:
 On Sun, 14 Jun 2009 17:29:21 +0400, grauzone <none example.net> wrote:

 Jarrett Billingsley wrote:
 On Sat, Jun 13, 2009 at 9:46 PM, zsxxsz<zhengshuxin hexun.com> wrote:
 It's good. But I think it should be implement by the DMD compiler, just
 like
 __FILE__  and __LINE__. __FUNCTION__ should be the base D language
 syntax same as
 __FILE__, __LINE__, in C99, they're all the compiler's things to get
 these and the
 compiler do these more easily than any library.

where does it end? Do we need __PACKAGE__, __MODULE__, __TYPE__, __TEMPLATE__, etc. etc. etc.? And I agree with them too - but you

provides module, filename, etc. fields. It even can be linked to the next enclosing scope to walk upwards nested functions and types. __FILE__ becomes __HERE__.filename, __LINE__ becomes __HERE__.line


Oh, but I want it to be called __LOCATION__! No, __CONTEXT__! :P

I think what he wanted to say is, it was proposed before and it was... ignored.
 I really don't care WHAT it's called or what its semantics are.  This
 is a simple problem.  This should not be hard to solve.  Bah.

Simple problems tend to be ignored. But because they don't go away themselves, they pile up and keep making life harder.
Jun 14 2009
prev sibling parent reply zsxxsz <zhengshuxin hexun.com> writes:
== Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s article
 On Sat, Jun 13, 2009 at 9:46 PM, zsxxsz<zhengshuxin hexun.com> wrote:
 It's good. But I think it should be implement by the DMD compiler, just l

 __FILE__ 燼nd __LINE__. __FUNCTION__ should be the base D language synt

 __FILE__, __LINE__, in C99, they're all the compiler's things to get thes

 compiler do these more easily than any library.

where does it end? Do we need __PACKAGE__, __MODULE__, __TYPE__, __TEMPLATE__, etc. etc. etc.? And I agree with them too - but you know, it'd be nice to actually get some results on these things once in a while instead of a bunch of bullshit bikeshed discussions. Sheesh.

What is the main use of __FILE__, __LINE__ and __FUNCTION__? Many people just use them for logging easily, including me. In some famous server such as Postfix, you may see 'const char *myname = "xxx"; ... msg_info("%s: xxx", myname);' in many files, it's a time cost for the programmer to do so. These are base requirments for D compiler.
Jun 14 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
zsxxsz escribi:
 == Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s article
 On Sat, Jun 13, 2009 at 9:46 PM, zsxxsz<zhengshuxin hexun.com> wrote:
 It's good. But I think it should be implement by the DMD compiler, just l

 __FILE__  and __LINE__. __FUNCTION__ should be the base D language synt

 __FILE__, __LINE__, in C99, they're all the compiler's things to get thes

 compiler do these more easily than any library.

where does it end? Do we need __PACKAGE__, __MODULE__, __TYPE__, __TEMPLATE__, etc. etc. etc.? And I agree with them too - but you know, it'd be nice to actually get some results on these things once in a while instead of a bunch of bullshit bikeshed discussions. Sheesh.

What is the main use of __FILE__, __LINE__ and __FUNCTION__? Many people just use them for logging easily, including me. In some famous server such as Postfix, you may see 'const char *myname = "xxx"; ... msg_info("%s: xxx", myname);' in many files, it's a time cost for the programmer to do so. These are base requirments for D compiler.

I never had to use them in other languages. Why? Because debugging support in them is excelent. So maybe enhancing debugging support for D is better than adding a couple of keywords just to make *printf debugging* better.
Jun 14 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
news:h149vq$21ku$1 digitalmars.com...
 zsxxsz escribi:
 == Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s 
 article
 On Sat, Jun 13, 2009 at 9:46 PM, zsxxsz<zhengshuxin hexun.com> wrote:
 It's good. But I think it should be implement by the DMD compiler, just 
 l

 __FILE__  and __LINE__. __FUNCTION__ should be the base D language synt

 __FILE__, __LINE__, in C99, they're all the compiler's things to get 
 thes

 compiler do these more easily than any library.

where does it end? Do we need __PACKAGE__, __MODULE__, __TYPE__, __TEMPLATE__, etc. etc. etc.? And I agree with them too - but you know, it'd be nice to actually get some results on these things once in a while instead of a bunch of bullshit bikeshed discussions. Sheesh.

What is the main use of __FILE__, __LINE__ and __FUNCTION__? Many people just use them for logging easily, including me. In some famous server such as Postfix, you may see 'const char *myname = "xxx"; ... msg_info("%s: xxx", myname);' in many files, it's a time cost for the programmer to do so. These are base requirments for D compiler.

I never had to use them in other languages. Why? Because debugging support in them is excelent. So maybe enhancing debugging support for D is better than adding a couple of keywords just to make *printf debugging* better.

Great, now try to take that language with great debugging support, and use it to do the same wonderful debugging on a *platform* that doesn't have excellent debugging support. Not everyone writes desktop apps. Besides, there's been plenty of times I've solved a problem using __blah__ and printf debugging in less time than it would have taken to fire up the debugger. And as for __FUNCTION__, that's useful for DRY.
Jun 14 2009
next sibling parent BCS <none anon.com> writes:
Hello Nick,

 "Ary Borenszweig" <ary esperanto.org.ar> wrote in message
 news:h149vq$21ku$1 digitalmars.com...
 
 zsxxsz escribi:
 
 I never had to use them in other languages. Why? Because debugging
 support in them is excelent. So maybe enhancing debugging support for
 D is better than adding a couple of keywords just to make *printf
 debugging* better.
 

use it to do the same wonderful debugging on a *platform* that doesn't have excellent debugging support. Not everyone writes desktop apps. Besides, there's been plenty of times I've solved a problem using __blah__ and printf debugging in less time than it would have taken to fire up the debugger. And as for __FUNCTION__, that's useful for DRY.

I've fixed a number of bugs with "fprintf" and a diff tool that I /still/ don't care to consider doing with just a debugger. And that's in C# under VS with one of the best debuggers ever written.
Jun 14 2009
prev sibling parent reply davidl <davidl nospam.org> writes:
在 Mon, 15 Jun 2009 12:43:55 +0800,BCS <none anon.com> 写道:

 Hello Nick,

 "Ary Borenszweig" <ary esperanto.org.ar> wrote in message
 news:h149vq$21ku$1 digitalmars.com...

 zsxxsz escribió:
  I never had to use them in other languages. Why? Because debugging
 support in them is excelent. So maybe enhancing debugging support for
 D is better than adding a couple of keywords just to make *printf
 debugging* better.

use it to do the same wonderful debugging on a *platform* that doesn't have excellent debugging support. Not everyone writes desktop apps. Besides, there's been plenty of times I've solved a problem using __blah__ and printf debugging in less time than it would have taken to fire up the debugger. And as for __FUNCTION__, that's useful for DRY.

I've fixed a number of bugs with "fprintf" and a diff tool that I /still/ don't care to consider doing with just a debugger. And that's in C# under VS with one of the best debuggers ever written.

However, you can understand how code runs much easier with a debugger rather than just read the source. For me, a debugger provides an easier way to understand code written by others. -- 使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
Jun 14 2009
parent BCS <none anon.com> writes:
Hello davidl,

 在 Mon, 15 Jun 2009 12:43:55 +0800,BCS <none anon.com> 写道:
 
 I've fixed a number of bugs with "fprintf" and a diff tool that I
 /still/ don't care to consider doing with just a debugger. And that's
 in  C# under VS with one of the best debuggers ever written.
 

rather than just read the source. For me, a debugger provides an easier way to understand code written by others.

most of the time the debugger is the tool for the job, some of the time, just give me __FILE__, __LINE__, printf and a club!
Jun 14 2009
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Ary Borenszweig wrote:
 zsxxsz escribi:
 == Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s 
 article
 On Sat, Jun 13, 2009 at 9:46 PM, zsxxsz<zhengshuxin hexun.com> wrote:
 It's good. But I think it should be implement by the DMD compiler, 
 just l

 __FILE__  and __LINE__. __FUNCTION__ should be the base D language synt

 __FILE__, __LINE__, in C99, they're all the compiler's things to get 
 thes

 compiler do these more easily than any library.

where does it end? Do we need __PACKAGE__, __MODULE__, __TYPE__, __TEMPLATE__, etc. etc. etc.? And I agree with them too - but you know, it'd be nice to actually get some results on these things once in a while instead of a bunch of bullshit bikeshed discussions. Sheesh.

What is the main use of __FILE__, __LINE__ and __FUNCTION__? Many people just use them for logging easily, including me. In some famous server such as Postfix, you may see 'const char *myname = "xxx"; ... msg_info("%s: xxx", myname);' in many files, it's a time cost for the programmer to do so. These are base requirments for D compiler.

I never had to use them in other languages. Why? Because debugging support in them is excelent. So maybe enhancing debugging support for D is better than adding a couple of keywords just to make *printf debugging* better.

__FILE__, __LINE__, __FUNCTION__, etc. are more often used for *logging* than for debugging. Of course, ideally, the logger would be able to identify all this stuff on its own (i.e. from a stack trace), but in a compiled language this is pretty tricky (impossible on Windows without debug symbols).
Jun 14 2009
parent reply zsxxsz <zhengshuxin hexun.com> writes:
== Quote from Robert Fraser (fraserofthenight gmail.com)'s article
 Ary Borenszweig wrote:
 zsxxsz escribi:
 == Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s
 article
 On Sat, Jun 13, 2009 at 9:46 PM, zsxxsz<zhengshuxin hexun.com> wrote:
 It's good. But I think it should be implement by the DMD compiler,
 just l

 __FILE__  and __LINE__. __FUNCTION__ should be the base D language synt

 __FILE__, __LINE__, in C99, they're all the compiler's things to get
 thes

 compiler do these more easily than any library.

where does it end? Do we need __PACKAGE__, __MODULE__, __TYPE__, __TEMPLATE__, etc. etc. etc.? And I agree with them too - but you know, it'd be nice to actually get some results on these things once in a while instead of a bunch of bullshit bikeshed discussions. Sheesh.

What is the main use of __FILE__, __LINE__ and __FUNCTION__? Many people just use them for logging easily, including me. In some famous server such as Postfix, you may see 'const char *myname = "xxx"; ... msg_info("%s: xxx", myname);' in many files, it's a time cost for the programmer to do so. These are base requirments for D compiler.

I never had to use them in other languages. Why? Because debugging support in them is excelent. So maybe enhancing debugging support for D is better than adding a couple of keywords just to make *printf debugging* better.

than for debugging. Of course, ideally, the logger would be able to identify all this stuff on its own (i.e. from a stack trace), but in a compiled language this is pretty tricky (impossible on Windows without debug symbols).

Yes, I agree with it.
Jun 14 2009
parent Sjoerd van Leent <svanleent gmail.com> writes:
zsxxsz Wrote:

 == Quote from Robert Fraser (fraserofthenight gmail.com)'s article
 Ary Borenszweig wrote:
 zsxxsz escribi:
 == Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s
 article
 On Sat, Jun 13, 2009 at 9:46 PM, zsxxsz<zhengshuxin hexun.com> wrote:
 It's good. But I think it should be implement by the DMD compiler,
 just l

 __FILE__  and __LINE__. __FUNCTION__ should be the base D language synt

 __FILE__, __LINE__, in C99, they're all the compiler's things to get
 thes

 compiler do these more easily than any library.

where does it end? Do we need __PACKAGE__, __MODULE__, __TYPE__, __TEMPLATE__, etc. etc. etc.? And I agree with them too - but you know, it'd be nice to actually get some results on these things once in a while instead of a bunch of bullshit bikeshed discussions. Sheesh.

What is the main use of __FILE__, __LINE__ and __FUNCTION__? Many people just use them for logging easily, including me. In some famous server such as Postfix, you may see 'const char *myname = "xxx"; ... msg_info("%s: xxx", myname);' in many files, it's a time cost for the programmer to do so. These are base requirments for D compiler.

I never had to use them in other languages. Why? Because debugging support in them is excelent. So maybe enhancing debugging support for D is better than adding a couple of keywords just to make *printf debugging* better.

than for debugging. Of course, ideally, the logger would be able to identify all this stuff on its own (i.e. from a stack trace), but in a compiled language this is pretty tricky (impossible on Windows without debug symbols).

Yes, I agree with it.

Perhaps not the first thing to think off, but what about webservices for example? They could use such a system. Though it should be more elaborate than just the function name. If you could do this with all scopes, it would be trivial to expose them.
Jun 15 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Jun 13, 2009 at 9:46 PM, zsxxsz<zhengshuxin hexun.com> wrote:
 It's good. But I think it should be implement by the DMD compiler, just l=

 __FILE__ =A0and __LINE__. __FUNCTION__ should be the base D language synt=

 __FILE__, __LINE__, in C99, they're all the compiler's things to get thes=

 compiler do these more easily than any library.

I completely agree, but Walter and Andrei's argument against it is - where does it end? Do we need __PACKAGE__, __MODULE__, __TYPE__, __TEMPLATE__, etc. etc. etc.? And I agree with them too - but you know, it'd be nice to actually get some results on these things once in a while instead of a bunch of bullshit bikeshed discussions. Sheesh.
Jun 13 2009
parent "Nick Sabalausky" <a a.a> writes:
"Jarrett Billingsley" <jarrett.billingsley gmail.com> wrote in message 
news:mailman.262.1244953393.13405.digitalmars-d puremagic.com...

 It's good. But I think it should be implement by the DMD compiler, just 
 like
 __FILE__ and __LINE__. __FUNCTION__ should be the base D language syntax 
 same as
 __FILE__, __LINE__, in C99, they're all the compiler's things to get 
 these and the
 compiler do these more easily than any library.

I completely agree, but Walter and Andrei's argument against it is - where does it end? Do we need __PACKAGE__, __MODULE__, __TYPE__, __TEMPLATE__, etc. etc. etc.? And I agree with them too - but you know, it'd be nice to actually get some results on these things once in a while instead of a bunch of bullshit bikeshed discussions. Sheesh.

I think a big part of the reasoning was that it would be better to just expand reflection to handle those things. But yea, it would be nice to have something in the meantime. I suppose it might not be too hard (for someone already used to working with the frontend source) to do a preprocessor that does that, or a custom patch (like I do for "warnings as warnings" and umm, you know, I actually forgot the other patch I'm using...).
Jun 14 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 14 Jun 2009 17:29:21 +0400, grauzone <none example.net> wrote:

 Jarrett Billingsley wrote:
 On Sat, Jun 13, 2009 at 9:46 PM, zsxxsz<zhengshuxin hexun.com> wrote:
 It's good. But I think it should be implement by the DMD compiler,  
 just like
 __FILE__  and __LINE__. __FUNCTION__ should be the base D language  
 syntax same as
 __FILE__, __LINE__, in C99, they're all the compiler's things to get  
 these and the
 compiler do these more easily than any library.

where does it end? Do we need __PACKAGE__, __MODULE__, __TYPE__, __TEMPLATE__, etc. etc. etc.? And I agree with them too - but you

All we need is a __HERE__, which expands into a struct literal that provides module, filename, etc. fields. It even can be linked to the next enclosing scope to walk upwards nested functions and types. __FILE__ becomes __HERE__.filename, __LINE__ becomes __HERE__.line

IIRC, it was previously proposed it as __SCOPE__
Jun 14 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sun, Jun 14, 2009 at 9:31 AM, Denis Koroskin<2korden gmail.com> wrote:
 On Sun, 14 Jun 2009 17:29:21 +0400, grauzone <none example.net> wrote:

 Jarrett Billingsley wrote:
 On Sat, Jun 13, 2009 at 9:46 PM, zsxxsz<zhengshuxin hexun.com> wrote:
 It's good. But I think it should be implement by the DMD compiler, jus=




 like
 __FILE__ =A0and __LINE__. __FUNCTION__ should be the base D language
 syntax same as
 __FILE__, __LINE__, in C99, they're all the compiler's things to get
 these and the
 compiler do these more easily than any library.

where does it end? =A0Do we need __PACKAGE__, __MODULE__, __TYPE__, __TEMPLATE__, etc. etc. etc.? =A0And I agree with them too - but you

All we need is a __HERE__, which expands into a struct literal that provides module, filename, etc. fields. It even can be linked to the nex=


 enclosing scope to walk upwards nested functions and types.

 __FILE__ becomes __HERE__.filename,
 __LINE__ becomes __HERE__.line

IIRC, it was previously proposed it as __SCOPE__

Oh, but I want it to be called __LOCATION__! No, __CONTEXT__! :P I really don't care WHAT it's called or what its semantics are. This is a simple problem. This should not be hard to solve. Bah.
Jun 14 2009