Thread overview | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
January 30, 2005 "compiler" variables? | ||||
---|---|---|---|---|
| ||||
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 Re: "compiler" variables? | ||||
---|---|---|---|---|
| ||||
Posted in reply to novice2 | 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 Re[2]: "compiler" variables? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Unknown W. Brackets | >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 Re: "compiler" variables? | ||||
---|---|---|---|---|
| ||||
Posted in reply to novice2 | Didn't there use to be a pragma(line) directive a long time ago? Or am I delusional..? |
January 30, 2005 Re: | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarrett Billingsley | 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 Re: | ||||
---|---|---|---|---|
| ||||
Posted in reply to Unknown W. Brackets | 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 Re: | ||||
---|---|---|---|---|
| ||||
Posted in reply to pragma | 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 Re: Re: | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kris | 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 > > |
Copyright © 1999-2021 by the D Language Foundation