• novice2 <novice2_member pathlink.com> Jan 30 2005
• "Unknown W. Brackets" <unknown simplemachines.org> Jan 30 2005
• novice2 <novice2_member pathlink.com> Jan 30 2005
• pragma <pragma_member pathlink.com> Jan 30 2005
• Kris <Kris_member pathlink.com> Jan 30 2005
• "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Jan 31 2005
• "Jarrett Billingsley" <kb3ctd2 yahoo.com> Jan 30 2005
• pragma <pragma_member pathlink.com> Jan 30 2005

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

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

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.

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

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

"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


 

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

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

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