January 30, 2005
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
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
>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
Didn't there use to be a pragma(line) directive a long time ago?  Or am I delusional..?


January 30, 2005
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
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
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
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