digitalmars.D - __FUNCTION__ implemented with mixins and mangles
- Jarrett Billingsley (45/45) Jun 12 2009 It's not foolproof, but I found it useful enough; maybe others will too.
- davidl (6/51) Jun 12 2009 Cool! But basing on mangled name might be broken in the future release o...
- Jarrett Billingsley (4/64) Jun 12 2009 Only if DMD is generating incorrect mangles now. Mangles are in the
- Robert Fraser (2/58) Jun 12 2009 Awesome, thanks!
- zsxxsz (4/4) Jun 13 2009 It's good. But I think it should be implement by the DMD compiler, just ...
- Jarrett Billingsley (10/14) Jun 13 2009 ax same as
- Nick Sabalausky (6/23) Jun 14 2009 I think a big part of the reasoning was that it would be better to just
- grauzone (6/19) Jun 14 2009 All we need is a __HERE__, which expands into a struct literal that
- Denis Koroskin (2/20) Jun 14 2009 IIRC, it was previously proposed it as __SCOPE__
- Jarrett Billingsley (6/31) Jun 14 2009 t
- grauzone (5/33) Jun 14 2009 I think what he wanted to say is, it was proposed before and it was...
- zsxxsz (6/21) Jun 14 2009 What is the main use of __FILE__, __LINE__ and __FUNCTION__? Many people...
- Ary Borenszweig (5/27) Jun 14 2009 I never had to use them in other languages. Why? Because debugging
- Nick Sabalausky (8/41) Jun 14 2009 Great, now try to take that language with great debugging support, and u...
- BCS (4/21) Jun 14 2009 I've fixed a number of bugs with "fprintf" and a diff tool that I /still...
- Robert Fraser (6/41) Jun 14 2009 __FILE__, __LINE__, __FUNCTION__, etc. are more often used for *logging*...
- zsxxsz (2/43) Jun 14 2009 Yes, I agree with it.
- Sjoerd van Leent (2/46) Jun 15 2009 Perhaps not the first thing to think off, but what about webservices for...
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
ÔÚ 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
Jarrett Billingsley <jarrett.billingsley gmail.com> 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:Only if DMD is generating incorrect mangles now. Mangles are in the spec; parsing them is completely valid, cross-platform and cross-compiler.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.
Jun 12 2009
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
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
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=ike__FILE__ =A0and __LINE__. __FUNCTION__ should be the base D language synt=ax same as__FILE__, __LINE__, in C99, they're all the compiler's things to get thes=e and thecompiler 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
"Jarrett Billingsley" <jarrett.billingsley gmail.com> wrote in messageI 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...).news:mailman.262.1244953393.13405.digitalmars-d puremagic.com...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 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
Jarrett Billingsley wrote:On Sat, Jun 13, 2009 at 9:46 PM, zsxxsz<zhengshuxin hexun.com> wrote: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__.lineIt'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 youknow, 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
On Sun, 14 Jun 2009 17:29:21 +0400, grauzone <none example.net> wrote:Jarrett Billingsley wrote:IIRC, it was previously proposed it as __SCOPE__On Sat, Jun 13, 2009 at 9:46 PM, zsxxsz<zhengshuxin hexun.com> wrote: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__.lineIt'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
Jun 14 2009
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:tJarrett 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=tAll 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=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.=A0I completely agree, but Walter and Andrei's argument against it is - where does it end? =A0Do we need __PACKAGE__, __MODULE__, __TYPE__, __TEMPLATE__, etc. etc. etc.? =A0And I agree with them too - but youOh, 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.enclosing scope to walk upwards nested functions and types. __FILE__ becomes __HERE__.filename, __LINE__ becomes __HERE__.lineIIRC, it was previously proposed it as __SCOPE__
Jun 14 2009
Jarrett Billingsley wrote:On Sun, Jun 14, 2009 at 9:31 AM, Denis Koroskin<2korden gmail.com> wrote:I think what he wanted to say is, it was proposed before and it was... ignored.On Sun, 14 Jun 2009 17:29:21 +0400, grauzone <none example.net> wrote:Oh, but I want it to be called __LOCATION__! No, __CONTEXT__! :PJarrett Billingsley wrote:IIRC, it was previously proposed it as __SCOPE__On Sat, Jun 13, 2009 at 9:46 PM, zsxxsz<zhengshuxin hexun.com> wrote: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__.lineIt'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 youI 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
== Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s articleOn Sat, Jun 13, 2009 at 9:46 PM, zsxxsz<zhengshuxin hexun.com> wrote: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.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 thecompiler 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 14 2009
zsxxsz escribió:== Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s articleI 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.On Sat, Jun 13, 2009 at 9:46 PM, zsxxsz<zhengshuxin hexun.com> wrote: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.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 thecompiler 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 14 2009
"Ary Borenszweig" <ary esperanto.org.ar> wrote in message news:h149vq$21ku$1 digitalmars.com...zsxxsz escribió: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.== Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s articleI 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.On Sat, Jun 13, 2009 at 9:46 PM, zsxxsz<zhengshuxin hexun.com> wrote: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.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 thecompiler 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 14 2009
Hello Nick,"Ary Borenszweig" <ary esperanto.org.ar> wrote in message news:h149vq$21ku$1 digitalmars.com...I've fixed a number of bugs with "fprintf" and a diff tool that I /still/ VS with one of the best debuggers ever written.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.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
ÔÚ Mon, 15 Jun 2009 12:43:55 +0800£¬BCS <none anon.com> дµÀ:Hello Nick,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/"Ary Borenszweig" <ary esperanto.org.ar> wrote in message news:h149vq$21ku$1 digitalmars.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 inzsxxsz 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.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
Hello davidl,ÔÚ Mon, 15 Jun 2009 12:43:55 +0800£¬BCS <none anon.com> дµÀ: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!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'sHowever, 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.
Jun 14 2009
Ary Borenszweig wrote:zsxxsz escribió:__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).== Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s articleI 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.On Sat, Jun 13, 2009 at 9:46 PM, zsxxsz<zhengshuxin hexun.com> wrote: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.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 thecompiler 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 14 2009
== Quote from Robert Fraser (fraserofthenight gmail.com)'s articleAry Borenszweig wrote:Yes, I agree with it.zsxxsz escribió:__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).== Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s articleI 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.On Sat, Jun 13, 2009 at 9:46 PM, zsxxsz<zhengshuxin hexun.com> wrote: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.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 thecompiler 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 14 2009
zsxxsz Wrote:== Quote from Robert Fraser (fraserofthenight gmail.com)'s articlePerhaps 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.Ary Borenszweig wrote:Yes, I agree with it.zsxxsz escribió:__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).== Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s articleI 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.On Sat, Jun 13, 2009 at 9:46 PM, zsxxsz<zhengshuxin hexun.com> wrote: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.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 thecompiler 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 15 2009