Re^7: Inline::C self-referential struct idioms and memory

I can only conclude that this is due to some change that has taken place since 5.10 (all my Inline C stuff is still tied to that build); and you are going to need more expertise than I have to track down the cause.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!

Comment on Re^7: Inline::C self-referential struct idioms and memory

Replies are listed 'Best First'.
Re^8: Inline::C self-referential struct idioms and memory by rutgeraldo (Novice) on Sep 04, 2015 at 21:28 UTC
Subsequent to this new convention I have been doing some more computer programming and have come to learn that in (Safe)free()-ing variables there is a difference between ones that are "automatically" allocated and ones that are "dynamically" allocated. I am told that the difference is that the former are allocated on the stack, the latter on the heap. Apparently you can only free() dynamically allocated ones on the heap; doing it on the other ones triggers the error. I guess I am doing that inside the destructor. In any case, commenting out the Safefree makes the error go away, for better or worse.	[reply]
Re^9: Inline::C self-referential struct idioms and memory by syphilis (Archbishop) on Sep 05, 2015 at 01:30 UTC
Apparently you can only free() dynamically allocated ones on the heap AIUI, when you create using Newx(), you are allocating dynamically - and you'll leak memory if you don't Safefree() those dynamically allocated variables when they go out of scope. Incidentally, DESTROY() doesn't have to be a perl sub. You could dispense with that perl sub and place it in the C code as something like (untested): `void DESTROY(Node* self) { warn("destroying self"); Safefree(self); }` [download] However, you may well find that there are additional things to Safefree (again untested): `void DESTROY(Node* self) { warn("destroying self"); Safefree(self-> parent); Safefree(self-> sv); Safefree(self); }` [download] Admittedly, you've then lost the identification of the actual object that's being Safefree'd - though I think that could be easily addressed. And I'm not sure how the self-referential nature of the Node object impacts upon things. Cheers, Rob	[reply] [d/l] [select]
Re^9: Inline::C self-referential struct idioms and memory by BrowserUk (Patriarch) on Sep 04, 2015 at 21:34 UTC
Thanks for coming back with the information. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :) In the absence of evidence, opinion is indistinguishable from prejudice. I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!	[reply]


Problems? Is your data what you think it is?
	PerlMonks