• novice2 (10/10) Jan 30 2005 Hello.
• Unknown W. Brackets (6/21) Jan 30 2005 Generally, the idea is to use assert, instead... because that is what
• novice2 (3/5) Jan 30 2005 Hmm.. I think compiler always know this information - current function, ...
• pragma (7/15) Jan 30 2005 Agreed. It's not really needed, but could help enrich *some* debug outp...
• Kris (4/21) Jan 30 2005 I've been asking for this too, so it can be added to the Log4J output. T...
• Matthew (7/42) Jan 31 2005 Agreed. This is far more than just a debug (i.e. "debug build") issue.
• Jarrett Billingsley (2/2) Jan 30 2005 Didn't there use to be a pragma(line) directive a long time ago? Or am ...
• pragma (8/10) Jan 30 2005 There's a "#line" directive, which is helpful for preprocessors:

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:






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





 _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