Neil Watkiss <[EMAIL PROTECTED]> writes:
> > > PS Neil Watkiss just pointed out to me that if I allowed the C 'inline'
> > > keyword to be used, the compiler could inline the C function in the XS
> > > wrapper. But he also points out that the complexity of getting from Perl
> > > to an XSub is an order of magnitude greater than the extra C function
> > > call.
> >
> > A small problem: C doesn't have an `inline' keyword (unless it's a
> > brand-new C9X/C0X thing, in which case it'll take a few years until
> > "most" compilers will support it).
> >
> > C++ has such a keyword.
>
> That's true. It's a gcc extension: gcc will accept either "inline" or
> "__inline__". Specifying the -ansi option turns off "inline", but still
> allows "__inline__". My point is that Inline currently won't bind to this
> function:
>
> __inline__ SV* JAxH(char *x) {
> return newSVpvf("Just Another %s Hacker", x);
> }
Good point. Of course, other compilers do it otherwise:
#pragma inline(JAxH)
SV* JAxH(char *x) {
return newSVpvf("Just Another %s Hacker", x);
}
on Sun, I think.
And we'd want to add `huge', `far' and `near' in preparation for their
presumable return, JIT for IA64...
Better, perhaps, to allow the caller to specify some list of allowed
additional "modifiers" (say "[qw/ __inline__ __far__ __near__ __huge__
/]")?
> Obviously writing code like this is not portable, and it's up to the
> author to deal with that. Inline shouldn't be responsible for syntax
> checking code anyway, that's what the compiler is for. If your compiler
> doesn't know __inline__, you'll soon know about it.
At least Inline could give a slightly more informative error message
than its usual...
--
Ariel Scolnicov |"GCAAGAATTGAACTGTAG" | [EMAIL PROTECTED]
Compugen Ltd. |Tel: +972-2-5713025 (Jerusalem) \ We recycle all our Hz
72 Pinhas Rosen St. |Tel: +972-3-7658117 (Main office)`---------------------
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555 http://3w.compugen.co.il/~ariels
