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__  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.
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