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
>

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

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