Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re^3: Perl 5 -> 6 do's and don'ts? (Inline::C)

by tye (Cardinal)
on Aug 01, 2003 at 19:43 UTC ( #280119=note: print w/ replies, xml ) Need Help??


in reply to Re: Re: Perl 5 -> 6 do's and don'ts?
in thread Perl 5 -> 6 do's and don'ts?

I'll somewhat disagree with Abigail-II and Elian.

Yes, if you want to interface Perl5 to a C library, then doing so via Inline::C is more likely to make it easy to port to Perl6 than using XS would (the XS porting might be available sooner, but you have much more risk of doing something that won't be handled if you use XS, IMHO).

Using Inline::C or XS to manipulate Perl data structures is something I simply don't recommend and I find that avoiding it when interfacing a library usually makes for a better design anyway.

C code that manipulates Perl data structures has always been the first thing to break when Perl is upgraded. So asking how to do that with Perl6 in mind calls the answer "Don't!" to mind (which is my answer anyway, just not as emphatically).

So when someone asks how to use XS with Perl 6 in mind, my advice is "Don't manipulate any Perl data structures in C and use Inline::C instead of XS." But, that is my advice anyway (again). And I'll bet that modules that follow that advice will eventually be able to work with Perl 6 without requiring any "by-hand" porting.

                - tye


Comment on Re^3: Perl 5 -> 6 do's and don'ts? (Inline::C)
Re: Re^3: Perl 5 -> 6 do's and don'ts? (Inline::C)
by Elian (Parson) on Aug 01, 2003 at 20:37 UTC
    I'll somewhat disagree with Abigail-II and Elian.

    Yes, if you want to interface Perl5 to a C library, then doing so via Inline::C is more likely to make it easy to port to Perl6 than using XS would (the XS porting might be available sooner, but you have much more risk of doing something that won't be handled if you use XS, IMHO).

    YHO would be very incorrect in this case. The issues involved are entirely those of the perl API, and have nothing to do with the means to generate the C code to access that API. There are no problems one will encounter with XS that one won't in Inline::C, and vice versa.

    The means of generating the C code has no bearing on the potential level of trouble. The issues are entirely ones of the perl API.

      You seem to have misunderstood my point. I don't care how the C code is generated.

      The issues involved are entirely those of the perl API

      Yes, and my point was that it can be very useful to write stuff in Inline::C that makes absolutely no reference to the perl API. You simply write C code that takes C-style arguments. If you do that, then you don't need any macros or processing of the source code other than whatever needs to happen to turn the perl subroutine arguments into C data types and to turn the returned C data type into a Perl scalar.

      And the available transformations to/from C data types are quite limited so you won't be doing anything in that part of your C code that won't be tons easier to implement than the whole typemap power of XS.

      Yes, you certainly can write Inline::C code that will be horribly hard to port. I thought you two covered that point rather well. But I don't consider that the most important point.

                      - tye

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://280119]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (5)
As of 2014-12-27 05:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (176 votes), past polls