www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - "compiler" variables?

reply novice2 <novice2_member pathlink.com> writes:
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_)
Jan 30 2005
next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
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_)
 
 
 

Jan 30 2005
next sibling parent novice2 <novice2_member pathlink.com> writes:
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.
Jan 30 2005
prev sibling parent reply pragma <pragma_member pathlink.com> writes:
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
Jan 30 2005
parent reply Kris <Kris_member pathlink.com> writes:
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

Jan 30 2005
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
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


Jan 31 2005
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
Didn't there use to be a pragma(line) directive a long time ago?  Or am I 
delusional..? 
Jan 30 2005
parent pragma <pragma_member pathlink.com> writes:
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
Jan 30 2005