On 26/09/02 18:55 -0700, Sean O'Rourke wrote:
> --- Ken Williams <[EMAIL PROTECTED]> wrote:
> > I wouldn't use comments if I were you, because they're awfully
> > ugly and contain too many points of head-scratching failure.
> > I'd prefer something more explicit:
> >
> > use Inline C
> > __END__
> > __C__
> > TYPEMAP(foo *, ...typemap code here...)
> >
> > void bar(foo* my_foo) {
> > }
(Ken)
Good idea. Would the macro perhaps generate nothing, and just be
something for the Inline parser to grok?
No matter what, I'm definitely interested in the cleaest and most
scalable solution. I think I made that comment extra ugly on purpose!
>
> But wouldn't that make it Inline "not-C"? *ducks*
(Sean)
In a certain sense Inline C is not just arbitrary C. For instance, you
always get free access to the Perl API which also includes all the
system headers.
Inline C is C code that can also act as glue code. Inline picks up as
many glue cues from the code as it can. It is only in instances when we
need more cues that we consider resorting to other measures.
>
> Seriously, it seems dangerous to me to make the C recognized by
> Inline an extended dialect. It seems much less painful to do
> something like this:
>
> use Inline C => type => 'foo *', '/* foo* typemap code */';
Specifying the cues on the Perl side is another way to do it. This would be
clumsy for things like function specific prototyping hints, but might be ok
for typemaps.
Let's wait and see what the use cases are. Then we can make a list of
options and take a vote.
Cheers, Brian
