On Tue, Dec 05, 2000 at 11:34:14AM -0800, [EMAIL PROTECTED] wrote:
> Joshua N Pritikin wrote:
> > >
> > > I just read C code produced by Inline and found that - correct me if
> > > I'm wrong - it just builds a wrapper around a C function.
> >
> > Oh! Indeed it does. Hm hm.
>
> I've been avoiding commenting on this thread, because these are Event
> issues, and as long as Inline is working properly 'with' Event, I'm
> happy.
>
> But I feel like too much attention is being given to the 'wrapper'
> issue. Inline just basically writes XS for you. The XS it writes is
> pretty straightforward and the wrapper is pretty thin. Anybody writing
> *straightforward* XS would do it pretty much the same way as Inline.
Not necessarily. Inline uses a peculiar style which exposes both entry
points. For example, it generates code like this:
--+--
int my_function(int xx) { return xx * xx; }
MODULE = Math PACKAGE = Math
void
my_function(int xx)
int xx:
PPCODE:
XPUSHs(newSViv(my_function(xx)));
--+--
As opposed to:
--+--
MODULE = Math PACKAGE = Math
void
my_function(int xx)
int xx:
PPCODE:
XPUSHs(newSViv(xx * xx));
--+--
> You
> almost always see XSUBS implemented as wrappers to native C functions.
> The typemapping has to happen somewhere.
But usually the body of the function is placed directly in the XSUB and
there isn't an extra function call. However,
> You have to keep it in perspective that we're coding in Perl, which is
> *way* slow (in this context). Inline's strength is in reducing the
> complexity by an order of magnitude. You can always write slightly
> faster code using XS, but what problem would you be solving?
i wasn't and am not considering performance at any point in this thread.
The concern here is whether the C & Perl APIs can match, from the point
of view of the naive developer.
--
May the best description of competition prevail.
(via, but not speaking for Deutsche Bank)
