Is there some mechanism for replacing these in D?

Evan

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
>

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

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

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

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

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

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.

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

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