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,


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


'null'

 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


frame

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


params

 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,


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




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


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