www.digitalmars.com         C & C++   DMDScript  

D - __FILE__ and __LINE__

reply Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:
Is there some mechanism for replacing these in D?

Evan
Oct 29 2002
parent reply "Walter" <walter digitalmars.com> writes:
At the moment, no. Their primary use in C is for the assert macro, which is
builtin to D. What are you using it for?

"Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message
news:aplteu$2lsm$2 digitaldaemon.com...
 Is there some mechanism for replacing these in D?

 Evan

Oct 29 2002
next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
I think that it should be an implicit part of exception handling, as well.  I
want to know what source line threw the original exception.

We'd talked a while ago about "chaining" exceptions, where you could have
Exception A, that is linked to Exception B (which caused it).  I would want, if
possible, to have line number information for each exception in the chain.

Perhaps the constructor for Error should get an implicit pair of arguments that
give the source file name and the line?

Walter wrote:

 At the moment, no. Their primary use in C is for the assert macro, which is
 builtin to D. What are you using it for?

 "Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message
 news:aplteu$2lsm$2 digitaldaemon.com...
 Is there some mechanism for replacing these in D?

 Evan


-- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Oct 29 2002
prev sibling next sibling parent reply Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:
Walter wrote:
 At the moment, no. Their primary use in C is for the assert macro, which is
 builtin to D. What are you using it for?
 
 "Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message
 news:aplteu$2lsm$2 digitaldaemon.com...
 
Is there some mechanism for replacing these in D?

Evan


Mostly my interest was for the garbage collection stuff that I'm preparing to work on and have talked about below, since it won't be that useful to have your referrer or where some garbage was allocated when you can't figure out where you allocated something without a lot of assembler interpreting rigamarole. Rather than assert, a common usage for then is when you're writing some sort of custom memory manager or leak collector in c++, and you do this: void* operator new(size_t size, int line, char const * const file ); void* operator new[](size_t size, int line, char const * const file ); Then set up some macros, like this: #define DEBNEW new( __LINE__, __FILE__ ) #define new DEBNEW transparently providing you with tagging for every allocation made with new. In order to make the the GC stuff that I want to do worth while, I need access to this kind of metadata. There will be overhead, of course, but not that much, just a string table for all of the file names, but only a few extra words for each entry. I was thinking of some sort of three mode system, where you could do DEBUG, RELEASE, and MEMDEBUG all independantly, since I can see situations where you wouldn't want or need the MEMDEBUG stuff that I'd like to add. Ex. Write a program in debug, test and document, turn debug off, then retest, turn memdebug on if you needed to tune your memory usage some, test again, compile release, test one final time, send it out. Something like that. I'm just trying to figure out all of the things that I'd need to write the additions that I'd like to write and plan it all out for when I get the time to actually do it. This is just something that popped into my head. Dunno if it'll be worth it to shove it into the lanugage. Evan
Oct 29 2002
next sibling parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

"Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message
news:apmiom$1v6i$1 digitaldaemon.com...

 Rather than assert, a common usage for then is when you're writing some
 sort of custom memory manager or leak collector in c++, and you do this:

 void* operator new(size_t size, int line, char const * const file );
 void* operator new[](size_t size, int line, char const * const file );

 Then set up some macros, like this:

 #define DEBNEW new( __LINE__, __FILE__ )
 #define new DEBNEW

 transparently providing you with tagging for every allocation made with
 new.

I have used this mechanism too. Though useful, I think it must be possible to implement a prettier mechanism based on symbolic debug information, where you could track the stack frames all the way back to main() giving method name, file name, and line number for each stack frame. It would be useful for error logging in some applications, too. Regards, Martin M. Pedersen
Oct 29 2002
next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
Java offers a neat solution,
create a new Exception Object but don't throw it.

if the D Exception Object had an interface to allow you to get info on the
stack frames i.e.(the file and line numbers of the functions you had
entered) and maybe the current file and line number: the location of the
'new'
you could do the same.
I would imagine that in non debug builds any calls would just return 'null'
no info available

depending on how people feel about programs self debugging, the stack frame
info (debug build) could contain enough info to access the locals and params
of the functions; get their names, and type info.
A snap shot of the stack would not have to be taken, unless the exception
was thrown (in which case each frame would need to be store safely in the
heap) there are issues with pointers to locals that will be not be
accessable directly, they would require redirecting to the snap shot.

Mike.

"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:apmnig$27rj$1 digitaldaemon.com...
 Hi,

 "Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message
 news:apmiom$1v6i$1 digitaldaemon.com...

 Rather than assert, a common usage for then is when you're writing some
 sort of custom memory manager or leak collector in c++, and you do this:

 void* operator new(size_t size, int line, char const * const file );
 void* operator new[](size_t size, int line, char const * const file );

 Then set up some macros, like this:

 #define DEBNEW new( __LINE__, __FILE__ )
 #define new DEBNEW

 transparently providing you with tagging for every allocation made with
 new.

I have used this mechanism too. Though useful, I think it must be possible to implement a prettier mechanism based on symbolic debug information,

 you could track the stack frames all the way back to main() giving method
 name, file name, and line number for each stack frame.

 It would be useful for error logging in some applications, too.

 Regards,
 Martin M. Pedersen

Oct 29 2002
parent "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:apmu5e$2flp$1 digitaldaemon.com...
 Java offers a neat solution,
 create a new Exception Object but don't throw it.

Yes, its neat - exept that "Exception" in this case is a misnomer. I would prefer that a StackTrace was something on its own - not bound to the exception concept.
 I would imagine that in non debug builds any calls would just return

 no info available

The DMD compiler has different flags for generating symbolic debug information, and controlling debug/release builds, so it should be possible to support it for release builds too. I expect, however, the line information would be less accurate for optimized code.
 depending on how people feel about programs self debugging, the stack

 info (debug build) could contain enough info to access the locals and

 of the functions; get their names, and type info.

Precisely - and it could be implemented entirely in Phobos, without altering the language itself.
 A snap shot of the stack would not have to be taken, unless the exception
 was thrown (in which case each frame would need to be store safely in the
 heap) there are issues with pointers to locals that will be not be
 accessable directly, they would require redirecting to the snap shot.

That is another reason to separate the StackTrace and Exception concepts :-) Regards, Martin M. Pedersen
Oct 29 2002
prev sibling next sibling parent reply Patrick Down <Patrick_member pathlink.com> writes:
In article <apmnig$27rj$1 digitaldaemon.com>, Martin M. Pedersen says...
Hi,

"Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message
news:apmiom$1v6i$1 digitaldaemon.com...

I have used this mechanism too. Though useful, I think it must be possible
to implement a prettier mechanism based on symbolic debug information, where
you could track the stack frames all the way back to main() giving method
name, file name, and line number for each stack frame.

It would be useful for error logging in some applications, too.

A stack dump mechanism would be very useful. It would also be nice if there was a variant of assert that would include a stack dump as part of the message. When an 'in' contract on a fuction is violated it would be nice to see which of the fifty places that function is called from violated the contract.
Oct 29 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:apn3u8$2m7n$1 digitaldaemon.com...
 A stack dump mechanism would be very useful.  It would also be nice
 if there was a variant of assert that would include a stack dump as
 part of the message.  When an 'in' contract on a fuction is violated
 it would be nice to see which of the fifty places that function is
 called from violated the contract.

I agree, but I think that's a debugger feature, and in fact, I use the debugger to do just that.
Nov 09 2002
parent Patrick Down <pat codemoon.com> writes:
"Walter" <walter digitalmars.com> wrote in news:aqk0c2$2c1a$1
 digitaldaemon.com:

 
 "Patrick Down" <Patrick_member pathlink.com> wrote in message
 news:apn3u8$2m7n$1 digitaldaemon.com...
 A stack dump mechanism would be very useful.  It would also be nice
 if there was a variant of assert that would include a stack dump as
 part of the message.  When an 'in' contract on a fuction is violated
 it would be nice to see which of the fifty places that function is
 called from violated the contract.

I agree, but I think that's a debugger feature, and in fact, I use the debugger to do just that.

But aren't asserts essentailly for debugging too? Those are in the langauge. It just seems that a stack dump would make them more effective.
Nov 09 2002
prev sibling parent "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
Having meaningful stack dumps possible makes bug reports so utterly much
more easy to deal with.  Can it be done without performance cost?  I know UT
does that but it seems like it requires a little runtime data manipulation.

Sean

"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:apmnig$27rj$1 digitaldaemon.com...
 I have used this mechanism too. Though useful, I think it must be possible
 to implement a prettier mechanism based on symbolic debug information,

 you could track the stack frames all the way back to main() giving method
 name, file name, and line number for each stack frame.

 It would be useful for error logging in some applications, too.

 Regards,
 Martin M. Pedersen

Oct 29 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
Ok, I understand.

"Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message
news:apmiom$1v6i$1 digitaldaemon.com...
 Walter wrote:
 At the moment, no. Their primary use in C is for the assert macro, which


 builtin to D. What are you using it for?

 "Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message
 news:aplteu$2lsm$2 digitaldaemon.com...

Is there some mechanism for replacing these in D?

Evan


Mostly my interest was for the garbage collection stuff that I'm preparing to work on and have talked about below, since it won't be that useful to have your referrer or where some garbage was allocated when you can't figure out where you allocated something without a lot of assembler interpreting rigamarole. Rather than assert, a common usage for then is when you're writing some sort of custom memory manager or leak collector in c++, and you do this: void* operator new(size_t size, int line, char const * const file ); void* operator new[](size_t size, int line, char const * const file ); Then set up some macros, like this: #define DEBNEW new( __LINE__, __FILE__ ) #define new DEBNEW transparently providing you with tagging for every allocation made with new. In order to make the the GC stuff that I want to do worth while, I need access to this kind of metadata. There will be overhead, of course, but not that much, just a string table for all of the file names, but only a few extra words for each entry. I was thinking of some sort of three mode system, where you could do DEBUG, RELEASE, and MEMDEBUG all independantly, since I can see situations where you wouldn't want or need the MEMDEBUG stuff that I'd like to add. Ex. Write a program in debug, test and document, turn debug off, then retest, turn memdebug on if you needed to tune your memory usage some, test again, compile release, test one final time, send it out. Something like that. I'm just trying to figure out all of the things that I'd need to write the additions that I'd like to write and plan it all out for when I get the time to actually do it. This is just something that popped into my head. Dunno if it'll be worth it to shove it into the lanugage. Evan

Oct 30 2002
prev sibling parent "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
Leak tracking code in the memory manager replacement.  ;)

Sean

"Walter" <walter digitalmars.com> wrote in message
news:apmgji$1qmu$3 digitaldaemon.com...
 At the moment, no. Their primary use in C is for the assert macro, which

 builtin to D. What are you using it for?

 "Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message
 news:aplteu$2lsm$2 digitaldaemon.com...
 Is there some mechanism for replacing these in D?

 Evan


Oct 29 2002