Muppet <[EMAIL PROTECTED]> writes:
>but the idiom of XS is to use PPCODE when you're returning more
>than one value. when people read your xsubs and see CODE they're going
>to be surprised when they find multiple values returned.
s/suprised/educated/ ;-)
>
>
>> Most of the time, my XSUBs follow this scheme:
>>
>> void
>> function (arg1, arg2)
>> type1 arg1;
>> type2 arg2;
>> CODE:
>> {
>> ...
>> EXTEND(SP, 3);
>> ST(0) = ...
>> ST(1) = ...
>> ST(2) = ...
>> XSRETURN(3);
>> }
>
>if you're going to write it that way, why use XS at all?
A. To get all the newXS calls built for us.
B. Let XS handle simple input typemaps.
>just write
>the perlapi C code directly.
We have ;-)
>
>you could just as easily have written
>
>void function (type1 arg1, type2 arg2)
> PPCODE:
> ...
> EXTEND (SP, 3);
> PUSHs (...);
> PUSHs (...);
> PUSHs (...);
>
The problem with that technique is that PPCODE adjusts SP
before calling body. So any references to incoming args in the body
are "above top of stack". If ones XS code calls back into perl
then they can get clobbered.
>
>>
>> For returning one boolean value, I'd always use one of
>> XSRETURN_(YES|NO):
Agreed.
>
>but, again, if you're returning one value, i don't understand why you
>don't want to let xsubpp and typemaps do the work for you.
If the default typemaps work that is fine, but if they don't there
is a tradeoff between writing a custom typemap and puting the
code inline in the XS code.
Quite often the "one value" that is being returned is say
an object from an XS written "new".
Typically there is only one of those so having an OUTPUT typemap
for it spreads the definition across two files.
