|
Archives
D Programming
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.ide
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
D.gnu
D
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
electronics
|
digitalmars.D - __FUNCTION__ implemented with mixins and mangles
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.
ÔÚ 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/
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.
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!
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.
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.
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.
== 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.
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.
"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.
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.
ÔÚ 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/
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!
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).
== 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.
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.
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.
"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...).
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__
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.
|
|
C & C++
DMDScript
davidl <davidl nospam.org> 