Re^4: When to (and not to) use sv

Yes, it compiles for me, but to your point I'll clean up the declarations within the post. I've been using C++ a lot more than C lately, and given the similarities in syntax between the two it starts to get easy to let one leak into the other. I learned Portuguese as a second language, and then picked up Spanish along the way a few years later. Both being romance languages, there are enough similarities that I found it necessary to concentrate on not slipping a Portuguese-specific word into my Spanish.

Thanks for taking a look at it. This is the sort of thing that if I'm going to invest the time in learning it, I want to learn it right.

I considered picking up the Extending and Embedding Perl book, but given that it came along before 5.8.8 (I think), there have been changes to XS since then that might make the book more trouble than it's worth. If anyone reading this knows otherwise let me know and I'll probably go pick up a copy somewhere. Meanwhile, POD, tinker, and more POD.

Dave

Comment on Re^4: When to (and not to) use sv_2mortal()

Replies are listed 'Best First'.
Re^5: When to (and not to) use sv_2mortal() by BrowserUk (Patriarch) on Oct 28, 2011 at 22:56 UTC
This is the sort of thing that if I'm going to invest the time in learning it, I want to learn it right. Once you get past the initial get something working stage is when it gets interesting and then frustrating. For example, in this version of your code I've stripped out a whole bunch of macros and it still compiles clean and runs leak-free. Unsuprisingly, it is a tad quicker: `int test_perlcall( int input ) { dSP; /* Declare and initialize local copy of Perl stack ptr / PUSHMARK(SP); XPUSHs(sv_2mortal(newSViv( input ))); PUTBACK; if( call_pv( "return_input", G_SCALAR ) != 1 ) croak( "Well, THAT failed to work.\n" ); return (int)POPi; / Inline::C handles this typemap automatically. + */ }` [download] But then you start wondering why all those apparently unneeded macros are used in the samples. They obviously are required on some occasions, but when? And why? It is answers to these questions that are much harder to obtain. 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". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply] [d/l]

Replies are listed 'Best First'.

Re^5: When to (and not to) use sv_2mortal()
by BrowserUk (Patriarch) on Oct 28, 2011 at 22:56 UTC

This is the sort of thing that if I'm going to invest the time in learning it, I want to learn it right.

Once you get past the initial get something working stage is when it gets interesting and then frustrating.

For example, in this version of your code I've stripped out a whole bunch of macros and it still compiles clean and runs leak-free. Unsuprisingly, it is a tad quicker:

int test_perlcall( int input ) {
    dSP;  /* Declare and initialize local copy of Perl stack ptr */

    PUSHMARK(SP);
    XPUSHs(sv_2mortal(newSViv( input )));
    PUTBACK;

    if( call_pv( "return_input", G_SCALAR ) != 1 )
        croak( "Well, THAT failed to work.\n" );

    return (int)POPi; /* Inline::C handles this typemap automatically.
+ */
}
[download]

But then you start wondering why all those apparently unneeded macros are used in the samples. They obviously are required on some occasions, but when? And why?

It is answers to these questions that are much harder to obtain.

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".

In the absence of evidence, opinion is indistinguishable from prejudice.

[reply]
[d/l]