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.