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_)

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_)
> 
> 
> 

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

Didn't there use to be a pragma(line) directive a long time ago?  Or am I delusional..?

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

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

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

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