D - __FILE__ and __LINE__
- Evan McClanahan (2/2) Oct 29 2002 Is there some mechanism for replacing these in D?
- Walter (4/6) Oct 29 2002 At the moment, no. Their primary use in C is for the assert macro, which...
- Russ Lewis (13/21) Oct 29 2002 I think that it should be an implicit part of exception handling, as wel...
- Evan McClanahan (30/39) Oct 29 2002 Mostly my interest was for the garbage collection stuff that I'm
- Martin M. Pedersen (10/19) Oct 29 2002 Hi,
- Mike Wynn (20/43) Oct 29 2002 Java offers a neat solution,
- Martin M. Pedersen (18/29) Oct 29 2002 Hi,
- Patrick Down (6/14) Oct 29 2002 A stack dump mechanism would be very useful. It would also be nice
- Walter (4/9) Nov 09 2002 I agree, but I think that's a debugger feature, and in fact, I use the
- Patrick Down (4/15) Nov 09 2002 But aren't asserts essentailly for debugging too? Those are in the
- Sean L. Palmer (7/14) Oct 29 2002 Having meaningful stack dumps possible makes bug reports so utterly much
- Walter (4/43) Oct 30 2002 Ok, I understand.
- Sean L. Palmer (5/12) Oct 29 2002 Leak tracking code in the memory manager replacement. ;)
Is there some mechanism for replacing these in D? Evan
Oct 29 2002
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
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...-- 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))) ]Is there some mechanism for replacing these in D? Evan
Oct 29 2002
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...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. EvanIs there some mechanism for replacing these in D? Evan
Oct 29 2002
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
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...whereRather 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
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'null'no info availableThe 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 stackframeinfo (debug build) could contain enough info to access the locals andparamsof 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
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
"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
"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...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.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
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,whereyou 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
Ok, I understand. "Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message news:apmiom$1v6i$1 digitaldaemon.com...Walter wrote:isAt the moment, no. Their primary use in C is for the assert macro, whichbuiltin to D. What are you using it for? "Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message news:aplteu$2lsm$2 digitaldaemon.com...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. EvanIs there some mechanism for replacing these in D? Evan
Oct 30 2002
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, whichisbuiltin 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