Beefy Boxes and Bandwidth Generously Provided by pair Networks Joe
We don't bite newbies here... much
 
PerlMonks  

Re: Re: Perl 5 -> 6 do's and don'ts?

by liz (Monsignor)
on Aug 01, 2003 at 09:54 UTC ( #279907=note: print w/ replies, xml ) Need Help??


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

Does that imply that using Inline::C as opposed to XS would be a good choice now?

Liz


Comment on Re: Re: Perl 5 -> 6 do's and don'ts?
Re: Perl 5 -> 6 do's and don'ts?
by Abigail-II (Bishop) on Aug 01, 2003 at 09:56 UTC
    Considering that Inline::C is just a layer over XS, I don't think so. (And can Inline::C already deal with modules using C?)

    Abigail

      At least Inline::C's abstraction layer could be easily ported to Perl 6. If inside your C code you're doing stuff to Perl (5)'s internals without using the proper macro's, then of course you're on your own.

      So I guess I would put using Inline::C for a new Perl 5 project over using XS, especially knowing that Inline::C will be in the 5.10 core.

      Liz

        Well, yes, but that's only when you are doing something in pure C. If you now do something in pure C, and use XS for it, porting it to Perl6/Parrot would be reasonable straightforward. But a lot of XS code deals with Perl internals, whether that's pure XS or Inline::C.

        especially knowing that Inline::C will be in the 5.10 core.

        Right. 5.10. When will that happen? After more than a year, we still have no 5.9.0, or even goals for 5.9.0. I might be pessimistic, but I think any new Perl development going on that's going to be released "soon" will be found in 5.8.2 and 5.6.2/3. I had hoped the p5p BOF in Paris would shed some light on the timepath for 5.10, but there wasn't anything in the minutes, so I guess it wasn't discussed.

        Abigail

Re: Re: Re: Perl 5 -> 6 do's and don'ts?
by Elian (Parson) on Aug 01, 2003 at 13:15 UTC
    No, it doesn't. The issue, such as it is, is with perl's API. XS is just a thin and somewhat brain-damaged macro layer over C, as is Inline::C. (Which, granted, is far less brain-damaged)

    Any non-specious reason to not use XS applies to Inline::C as well.

Re^3: Perl 5 -> 6 do's and don'ts? (Inline::C)
by tye (Cardinal) on Aug 01, 2003 at 19:43 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).

    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
      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://279907]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (15)
As of 2014-04-16 16:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (432 votes), past polls