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

The '#define CLASS "Node"' is picked up in the typemap (right?). So this should also work for definitions in separate source and header files, presumably.

Yes. In theory, you could add the O_OBJECT input and output mappings into the default typemap file; and then all you'd need in the typemap for any given XS class is the name typedef:
```
Node *          O_OBJECT
[download]
```
I did try it once but couldn't quite get it to work and I've stuck with this typemap ever since.
For the output in the typemap I guess we do have to make a new SV* every time, and bless it?

Remember what is being created is just another reference (RV) not the object itself.
I cannot say with 100% certainty that it is the only way to do it; just that it works.
I suspect it is necessary because what you pass back will get assigned to a Perl variable; which will go out of scope and get cleaned up.
You might try to avoid that by managing the reference count of the reference to the object; but its not the way perl usually does things.
I assume my not doing sv_setref_pv was behind those "bizarre copy" warnings, correct?

Probably, but once again, I cannot say for sure. Like most XS programmers; a large part of the code I use is essentially cargo-culted.
You find something that works and stick with it because the alternative is an endless cycle of trial and error.
For the input in the typemap, can I just skip the checks and jump straight to INT2PTR?

Probably. But I think that conditional check costs so little; and the information it give when someone does pass the wrong thing is so useful; I would only do so if I was really desperate for performance.
And then only if removing it actually made a significant difference to that performance; which I doubt.
Is it madness to try to come up something by myself and should I just use an AV*?

The answer to that really depends on how dynamic the children are; but AVs are pretty cheap and very flexible. I'd only avoid them if I could substitute a fixed-size C array and know it would cater for all circumstances.
If I set children, based on my logic of recursive cleanup from root to tips, am I correct to think I can SvREFCNT_inc in the setter and decrement all the children in the destructor, then clear out the container?

I can't answer that. I'd have to try it out and see what works.

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^3: Inline::C self-referential struct idioms and memory Select or Download Code

Replies are listed 'Best First'.
Re^4: Inline::C self-referential struct idioms and memory by rutgeraldo (Novice) on Sep 04, 2015 at 16:00 UTC
Mmmm... I'm trying out your version and I'm getting: `perl(50784,0x7fff7dec7310) malloc: * error for object 0x100000000000 +0000: pointer being freed was not allocated * set a breakpoint in malloc_error_break to debug` [download] Presumably some kind of variation in Perl and OS? I notice you're on windows. I'm on OSX10.9, Perl version 5.16.2. ETA: the address 0x7fff7dec7310 is not any of the ones that show up in the Devel::Peek::Dump() outputs, by the way.	[reply] [d/l]
Re^5: Inline::C self-referential struct idioms and memory by BrowserUk (Patriarch) on Sep 04, 2015 at 16:15 UTC
Presumably some kind of variation in Perl and OS? I guess. When (chronologically) does that output appear? 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]
Re^6: Inline::C self-referential struct idioms and memory by rutgeraldo (Novice) on Sep 04, 2015 at 20:20 UTC
If I only call the constructors but no getter/setters, and I put a while(1){} at the end of Node.pl it doesn't happen, the script just "waits" (loops). So one thing that triggers it is global object destruction. If I call set_parent($p), then an infinite loop, I notice that the destructor is triggered on the invocant $node (but not on $p). The malloc error doesn't happen. Note that the setter is not void: it returns the invocant. So there's a side effect to the conversion of the output in the typemap that makes a refcount drop to zero somewhere, triggering object destruction. However, a blessed reference to Node* is still returned. If I call set_parent twice, the malloc error happens.	[reply]
Re^7: Inline::C self-referential struct idioms and memory by BrowserUk (Patriarch) on Sep 04, 2015 at 20:45 UTC
Re^8: Inline::C self-referential struct idioms and memory by rutgeraldo (Novice) on Sep 04, 2015 at 21:28 UTC
Some notes below your chosen depth have not been shown here