Hi all,
I think I send my answer directly to Brian so I repeat one or two important
point here:
- Inline and Perl 6.0, If perl 6.0 comes out before the book (which I hope
not for you Brian) I wouldn't buy it if it didn't contain a specific section
on perl 6. What is the status of XS in perl 6, there were talks about
abandoning it in favor of Inline.
- A book without real world examples is not worth much. Some of us could
certainly contribute some of the goodies they have written.
- Type maps
> > use Inline C
> > __END__
> > __C__
> > /* Inline: typemap: 'foo *'
> > *typemap code here*
> > */
> > void bar(foo* my_foo) {
> > }
Brian it's good that you said that this example wasn't very good in a
follow-up mail. You must have forced yourself to write something that ugly.
> use Inline C
> __END__
> __C__
> TYPEMAP(foo *, ...typemap code here...)
>
> void bar(foo* my_foo) {
> }
>
> -Ken
This is good, very clean. Now some remarks and critics which I hope you'll
take positively (I understand that this was a fast explanation of your
ideas. Strange I have the feeling I am apologizing twice here, before I've
said anything, I am getting old or diplomatic or worse :-).
I have just implemented RPC on our platform and I had to write
a-kind_of-idl-compiler. I also went for this type of template. Some remarks:
1/ Typemaps defined locally were the types are used (good, C++ thinking) I
go against what Sean wrote.
(sean)use Inline C => type => 'foo *', '/* foo* typemap code */';
that doesn't we MUST not do it that way, only that the other way is more
localized to the code.
2/ Good, inlined code and optimized away if not used
3/ Not good, code is not reused if the compilation unit for 2 Inline::C
modules is not the same (this is a more an Inline problem, that I took up
some times ago but no one seemed intressed in getting multiple Inline::C
pieces in the same compilation unit)
In my case I have defined the following templates:
RPC_INCLUDE_PROXY<./GlobalProxyTemplate>
which includes proxies that I want to reuse. Then:
RPC_FUNCTION< int , SomeFunction , int, int>
I a proxy for SomeFunction exists in the included template it is used,
otherwise a new proxy is generated. TO avoid name clash every template has
it's own namespace.
4/ so-so: TYPEMAP(foo *, ...typemap code here...), I don't like the idea of
putting code in the template, it's fine for very short code only. I think
the following could be better
TYPEMAP(foo *, FooPointerConverter) ;
Foo * FooPointerConverter(...)
{
your code here
}
This is very C++-ish. For the real code warrior who use MFC, this does look
like an event map (typemaps are event maps masqueraded, the event being the
function call)
The only point is that we are now forced to parse the C code instead for
only parsing the typemap, arghh what Sean write after all?
If we avoid the *!�$^$* parser we have Inline.43 it should be ok.
Nadim Khemir
Senior Software Engineer
E-mail : [EMAIL PROTECTED]
Internet : www.cpen.com
C Technologies AB
Ideon Research Park
Scheelev�gen 19c, SE-223 70 Lund
Sweden
