Vladimir Panteleev Wrote: > On Wed, 18 May 2011 02:18:22 +0300, Jesse Phillips > <[email protected]> wrote: > > > [snip memory corruption rant] > > I've nothing to contribute but by own anecdotal experience. So: are you > doing *any* allocations or throwing exceptions in finalizers (destructors > of objects on the heap)? If you are, don't do it. :P > > -- > Best regards, > Vladimir mailto:[email protected]
Well I do use allocations to get values out of dll calls, but I didn't want to negotiate ownership so I duplicated everything it gave me and promptly freeing it through the free function it provides, and I ignore ownership of the values I give it (so I wouldn't be surprised if I had memory leaks, but it's not like the DLL will tell me when it is done with the memory) As for the destructor thing, I'll have to check, I originally tried to use a reference counted struct and believe I may had thown something in a destructor there (think that one is safe?). But when I move to class I'm pretty sure I just gave up on cleaning up. I mean I'm done with it when I exit my program anyway. And thing thing is that it is consistent. In that a build that fails will always fail and a build the succeeded always continues to function. So not only should it not be destroying anything yet, it really seems to be how the code is generated. I actually had a print statement which printed some values of StopWatch, and I could consistently use that to get an access violation, and I just hoped I wouldn't have any more issues. What does D do when it runs out of stack space? (Not that it is likely I am)
