> I would ask you to drop the sarcasm though. It's not that it offends me but
> rather that it confuses your point in some cases.
i'll try. some of it is natural though :(.
> Admittedly, Neil has done a lot more work on C++ than I have on C. Most of
> this is because C++ is much more involved. I'll work with Neil to integrate
> the overlapping bits for the next release.
it might be convenient to integrate some of the documentation too, so a person
doesn't have to work so hard to identify what is C++ specific.
typically the fastest path to code re-use is copy-and-modify, but it might be time
to start cleaning some of that up.
> Inline has always be optimized for the first two, and not so much for the
> third [re-using an existing C library]. Dumping existing code into your Perl may
>work, but that's not my
> style. If you have existing code, you probably should compile it separately
> and write nice new interface code inline. Good C interfaces generally make
> lousy Perl interfaces. But TMTOWTDI.
if there is a pre-existing library, typically there is also a bunch of documentation
for it.
also, i'd never want to get in the way of some perl programmer who wants to get
down to the metal of the low-level api.
what i sometimes find myself wanting to do is to have the directly mapped C api
available in perl, then write the convenient perl-style public glue code in perl,
so that people have access to both.
how often have you used the POSIX module? it is pretty nice to have available,
when nothing else will work.
i'm hitting this issue big time with the DBD database libraries. They tend to do
do a lot of glue work in C, between perl and the original library.
This prevents me from working around their mistakes or limitations, assuming
i'm willing to re-write their perl, but not willing to drag out a C compiler.
For example: most database programmers don't care to set transaction isolation
parameters. So practically all DBD libraries set them to default -- in C.
The perl programmer can do nothing about it. Also, they might decide to
throw away some of the lesser-used information returned back from metadata
queries -- in C. I can't do much about that from perl.
> > Note also that the 'Preprocess' filter uses this command:
> >
> > $Config{cpprun},
> > $Config{cppflags},
> > "-I$Config{archlibexp}/CORE",
> > @{$ilsm->{ILSM}{MAKEFILE}{INC}||[]}
> >
> > which excludes CCFLAGS and OPTIMIZE (not to mention ignoring CC). So the result
> > may not match what the compiler does in the compile phase.
this was a bug report, btw.
> > Q: But even with preprocessing, Inline won't deal with typedefs will it?
> >
> > A: Not unless you provide a filter which does that. Inline uses a string match
> > on whatever type name is given in the function declaration, and looks that up
> > in the typemap file. Sometimes, most of the time this is a good thing, because
> > you often don't want to treat all char* typedefs the same way, for example.
> > (Note that SWIG has support for a typedef declaration.)
>
> I don't understand the third sentence.
yeah, it got garbled somewhere on the way out of my brain.
there are several issues here:
1. sometimes an "int*" in a function declaration means a different thing from function
to function. so you need some per-function sugar to note that.
2. sometimes an added level of indirection in the typemap declaraction is convenient
for maintainability, so you can say "treat an unsigned long the same as an unsigned
int,
whatever that is". this is a typedef-like operation that appears just in the typemap.
3. sometimes you'd like your wrapper generator to look at the literal type names
in the declaration, and sometimes you'd like it to look up what that type is typedef'd
too before consulting the typemap. for example, in a typical ugly Windows api,
there are declarations involving things like DWORD, WORD, LPVOID, and
so on. I'd rather write a typemap for the corresponding C data types.
all of these things are bigger issues for wrapping pre-existing libraries.
>
> >
> > Q: Why isn't the Inline::Filters module part of the base Inline distribution?
> >
> > A: Because Brian Ingerson and Neil Watkiss are different people, and
> > it isn't like they work for the same company, so that coordination would be easy.
>
> I can't be sure how high the sarcasm level is here. Neil and I talk several
> times a day usually. We did work at the same company until recently. We will
> continue to support Inline together for the forseeable future.
>
> Inline::Filters is a fairly young hack. It may eventually be distributed with
> Inline. But Neil would have to give the code to me, and I'd rather have _him_
> working on it for now.
sorry, the sarcasm was too high.
my point here was to help someone like myself who is coming new to Inline, and
expecting to get everything needed in one package download.
then he discovers that even though the documentation and the code reference
filters regularly, they aren't there.
there are cpan packages involving multiple authors. it can be done :).
> > Q: What does AUTOWRAP do?
> >
> > A: No, this option does not wrap long lines. Rather, it makes the builtin C parser
> > look for function *declarations*, in addition to function *definitions*.
> > The same grammar is used; it is just that more is taken from it.
> > Oh, and currently Inline::CPP always takes declarations, regardless of AUTOWRAP.
>
> You need to take people's real life situations into mind when you implement
> something. Binding to declarations may not be what you want, so you need an
> option to turn it off. Thus AUTOWRAP. You could make it the default, but that
> might break existing code. If you are going to break code, do it on a major
> release. AUTOWRAP will probably happen by default in release 0.50. (The next
> major release) Inline::CPP has more flexible options because far less people
> use it.
i can't believe people's requirements differ in this area between C and C++,
and even if they did, documentation and option consistency would be a boon.
> use Inline 'CPP';
> use Inline 'C++';
> use Inline 'CPlusPlus';
>
> If you ask Neil nicely, I'm sure he'll add CXX. ;)
actually what was really throwing me for a loop was the code, since it does
actually involve the preprocessor and the "real" cpp sometimes, in addition to C++,
and "cpp" is used in the code for both.
it may be too late to clean up, and since i can't pledge to be pitching in and fixing
it, i should probably keep mum.
but windows developers should certainly realize that there is a substantial body
of unix C++ programmers who think "c preprocessor" when they see "cpp".
> > Q: How do I get my #define's, const variables, and enum's automatically converted
> > to perl constants?
> >
> > A: You don't, at least not with Inline. You could try SWIG.
>
> You obviously know a lot more about SWIG than I. If you'd like to work with
> me, I'll be glad to see which things make good sense to Inline.
actually i don't know all that much about SWIG. i used it a few times years ago.
i do have some familiarity with the general issues confronting any C interface wrapper,
however (from working at pure atria/rational where it was necessary to write
interception/tracing
code for a variety of pre-existing libraries).
also about the many IDL syntaxes, which have to address these issues in order
to "remote-ize" apis.
i'm not actually an advocate for SWIG.
i find it hard to use, and its documentation never seems to quite address whatever
particular question i have. Inline doesn't either, but Inline is small enough a person
can sit down and read all the code.
i like Inline's approach of making the easy things easy.
however, right now, for a variety of purposes, in Inline the hard things are
impossible,
whereas with SWIG they are possible.
> I agree that Inline is lacking in output parameter facilities. In general I
> disfavor output parameters. They produce bad Perl interfaces. Perl
> programmers expect list returns.
>
> If you really want to modify by reference, you should pass in by SV* and do
> it yourself.
>
> I've always stood behind the philosophy of taking time to handcraft great
> interfaces, rather than autogenerate shoddy ones. In general, most of your
> Inline code should be *interface* code.
i agree with this in principle, except for the observation earlier, which is that
i'd rather get "out of C" as soon as possible in the layering between perl
and the native library. i can then do my convenience wrappers in perl,
where someone else can workaround my bad decisions about what is
convenient.
> > A: XS will verify that the number of arguments is correct (unless
> > ellipses are used). XS will also verify that the type of arguments
> > is correct.
we should probably clarify:
verify that the type (the "perl type", not C type) ...
> > Of course, your C program can still crash, by making
> > assumptions about the value within the range of the type, or doing
> > bad things with free or malloc, etc. The Inline module does not
> > support constraint declarations, like SWIG.
>
> This seems interesting. One problem Inline has to overcome is how to specify
> extra semantics in the C code. Since the C code *is* the glue code, all
> semantics need to be valid C. Some have suggested comment based hints.
yes, and SWIG also uses its own evolutionary-grown IDL.
myself, i'd rather use a standard IDL (there are many to choose from),
because those are designed for a very similar purpose (remoting an API is typically
intrinsically cross-language).
however, that would introduce a barrier to entry for use.
at some point, i'll probably hack that together. then someone can use my module
to generate Inline from IDL, and then use Inline to generate SWIG, and then
use SWIG to generate XS :)
-mda
