View mode: basic / threaded / horizontal-split · Log in · Help
January 30, 2005
"compiler" variables?
Hello.
Is where so called "predefined compiler variables" in D, such as "current
module", "current function", "current line number" and so on?

It would be make easier bebug messages. Something like this:

#
# int func1(int param)
# {
#    debug printf("%.*s called with param=%d", _FUNC_, param);
#    if(param<0) printf("runtime error at %.*s-*%s-*%s", _MODULE_, _FUNC_,
_LINE_)
January 30, 2005
Re: "compiler" variables?
Generally, the idea is to use assert, instead... because that is what 
__FILE__ and __LINE__ are almost always used for - debuggin information, 
as you said.

The downside is there's no way to *pass* this debugging information, but 
otherwise it's not the huge a limitation.

-[Unknown]


> Hello.
> Is where so called "predefined compiler variables" in D, such as "current
> module", "current function", "current line number" and so on?
> 
> It would be make easier bebug messages. Something like this:
> 
> #
> # int func1(int param)
> # {
> #    debug printf("%.*s called with param=%d", _FUNC_, param);
> #    if(param<0) printf("runtime error at %.*s-*%s-*%s", _MODULE_, _FUNC_,
> _LINE_)
> 
> 
>
January 30, 2005
Re[2]: "compiler" variables?
>The downside is there's no way to *pass* this debugging information, but 
>otherwise it's not the huge a limitation.

Hmm.. I think compiler always know this information - current function, module,
line number etc.
May be (i hope) Walter include support for this in dmd later.
January 30, 2005
Re: "compiler" variables?
Didn't there use to be a pragma(line) directive a long time ago?  Or am I 
delusional..?
January 30, 2005
Re:
In article <ctivj4$5nb$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>Didn't there use to be a pragma(line) directive a long time ago?  Or am I 
>delusional..? 
>
>

There's a "#line" directive, which is helpful for preprocessors:

#line number "filename"

Example:

#line 42 "original_file.xml"
#line 23 "index.dsp"

Hope that's what you were looking for.

- EricAnderton at yahoo
January 30, 2005
Re:
In article <cti90n$1qts$1@digitaldaemon.com>, Unknown W. Brackets says...
>
>Generally, the idea is to use assert, instead... because that is what 
>__FILE__ and __LINE__ are almost always used for - debuggin information, 
>as you said.
>
>The downside is there's no way to *pass* this debugging information, but 
>otherwise it's not the huge a limitation.

Agreed.  It's not really needed, but could help enrich *some* debug output.  If
we had something like:

> writefln("problem on line: ",debug.lineno," (",debug.file,")");

..wouldn't be too much of a wart on the language, IMO.  Tying in that kind of
info to the 'debug' pseudo-scope would at least avoid any mistake of trying to
get this information in a release build:

> c:\>dmd myfile.d
> Error myfile.d(xx): cannot use 'debug' scope in release build.

- EricAnderton at yahoo
January 30, 2005
Re:
I've been asking for this too, so it can be added to the Log4J output. T'would
be very helpful indeed.

- Kris


In article <ctj99l$pef$1@digitaldaemon.com>, pragma says...
>
>In article <cti90n$1qts$1@digitaldaemon.com>, Unknown W. Brackets says...
>>
>>Generally, the idea is to use assert, instead... because that is what 
>>__FILE__ and __LINE__ are almost always used for - debuggin information, 
>>as you said.
>>
>>The downside is there's no way to *pass* this debugging information, but 
>>otherwise it's not the huge a limitation.
>
>Agreed.  It's not really needed, but could help enrich *some* debug output.  If
>we had something like:
>
>> writefln("problem on line: ",debug.lineno," (",debug.file,")");
>
>..wouldn't be too much of a wart on the language, IMO.  Tying in that kind of
>info to the 'debug' pseudo-scope would at least avoid any mistake of trying to
>get this information in a release build:
>
>> c:\>dmd myfile.d
>> Error myfile.d(xx): cannot use 'debug' scope in release build.
>
>- EricAnderton at yahoo
January 31, 2005
Re: Re:
Agreed. This is far more than just a debug (i.e. "debug build") issue. 
Large and/or complex systems will certainly profit from this in 
"release" modes, since such systems oftentimes need/use debugging 
constructs in order to assist with the inevitable flaws. It's also 
useful for own-rolled profiling

"Kris" <Kris_member@pathlink.com> wrote in message 
news:ctje2h$14d4$1@digitaldaemon.com...
> I've been asking for this too, so it can be added to the Log4J output. 
> T'would
> be very helpful indeed.
>
> - Kris
>
>
> In article <ctj99l$pef$1@digitaldaemon.com>, pragma says...
>>
>>In article <cti90n$1qts$1@digitaldaemon.com>, Unknown W. Brackets 
>>says...
>>>
>>>Generally, the idea is to use assert, instead... because that is what
>>>__FILE__ and __LINE__ are almost always used for - debuggin 
>>>information,
>>>as you said.
>>>
>>>The downside is there's no way to *pass* this debugging information, 
>>>but
>>>otherwise it's not the huge a limitation.
>>
>>Agreed.  It's not really needed, but could help enrich *some* debug 
>>output.  If
>>we had something like:
>>
>>> writefln("problem on line: ",debug.lineno," (",debug.file,")");
>>
>>..wouldn't be too much of a wart on the language, IMO.  Tying in that 
>>kind of
>>info to the 'debug' pseudo-scope would at least avoid any mistake of 
>>trying to
>>get this information in a release build:
>>
>>> c:\>dmd myfile.d
>>> Error myfile.d(xx): cannot use 'debug' scope in release build.
>>
>>- EricAnderton at yahoo
>
>
Top | Discussion index | About this forum | D home