in reply to XS design question

To append somewhat to what starbolin noted and to more directly answer your questions (though I mostly aggree, and will partially re-iterate what starbolin has already said:

1) You can manipulate the Perl stack anywhere you want, really; as long as you do it right.
2) I would aggree with starbolin in that this design might not be the greatest. If you really want this module to be in XS, I would try to stick to a couple philosophies I follow (take it as a grain of salt, though): white your XS like you would write your Perl. In this case, you wouldn't want to write a PP module that would impicitly push onto a list to be returned so that another routine would be able to return it. Although it would work, it would be confusing and tough to debug and/or modify at a future date.

Everything considered, it is a little hard to say what the 'right' way to do it would be without a little more knowledge on the problem scope. Perhaps dropping some psudo code as a comment might better explain the module and what you are trying to do with it, therefore allowing for better analysis. Otherwise, I hope this addendum helps out a little and good luck with your module!

ha||ta

Replies are listed 'Best First'.
Re^2: XS design question (XS like C)
by tye (Sage) on Jul 11, 2006 at 15:55 UTC
    [write] your XS like you would write your Perl

    My XS philosophy is "write XS code like C code, and provide a C-friendly interface". I'm not sure my philosophy actually conflicts with yours, even though it sounds somewhat opposite. I find that the more Perl-like code you put into XS, the more fragile the results are (in multiple ways).

    So I'd write the wrapper functions in Perl and write one XS function that takes C-friendly arguments and returns C-friendly results and let the Perl code check for list vs. scalar context etc. That usually results in cleaner, simpler, easier to maintain and extend and more powerful code.

    - tye