in reply to Re: Inline::C self-referential struct idioms and memory
in thread Inline::C self-referential struct idioms and memory

Great, thanks! I really like what that constructor has turned into. Lessons learned:

Anyway, thanks - great answer! What do you advise in terms of managing child nodes in a container? These trees are not binary so I need a container member in the Node struct that can grow and shrink. Is it madness to try to come up something by myself and should I just use an AV*? 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?

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

Replies are listed 'Best First'.
Re^3: Inline::C self-referential struct idioms and memory
by BrowserUk (Patriarch) on Sep 04, 2015 at 15:32 UTC

    • 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!
[reply]
[d/l]
[select]

      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]
[reply]

In Section Seekers of Perl Wisdom