|
Re: Binding C libraries
by saintmike (Vicar) on Feb 08, 2005 at 04:47 UTC
|
For more info and examples of the actual binding process, check Inline::C, perlxs, and SWIG.
Regarding the interface, it depends on your application. If you want to share a bit more about what kind of library you're binding, we'll be able to give a couple of hints. | [reply] |
Re: Binding C libraries
by zentara (Cardinal) on Feb 08, 2005 at 12:10 UTC
|
At EmbeddingPerl you can get the source code for the book. There are alot of simple examples in there, that should get you going, even without the book ( you will still need perldocs :-) ).
You can first test your connection to your lib with InlineC, like:
use Inline C => Config =>
LIBS => '-L/path/to/the_static_lib -lyourlib';
use Inline C => <<'EOC';
#include "yourlib.h"
int wrap_multiply(int a, int b) {
return multiply(a,b);
}
EOC
I'm not really a human, but I play one on earth.
flash japh
| [reply]
[d/l] |
Re: Binding C libraries
by BUU (Prior) on Feb 08, 2005 at 06:47 UTC
|
As for the interface, it's a simple decision. If the functions have no overt relationship to each other (beyond perhaps a similar type of usage), that is, calling one function will *never* affect another function, then it should have a simple procedural. Other wise, if you have a strong desire to associate data with the functions, use an object oriented method. | [reply] |
Re: Binding C libraries
by adamk (Chaplain) on Feb 08, 2005 at 07:33 UTC
|
The prevailing attitude seems to be OO with added procedural options if you can provide the functionality in a simple one-shot function.
Regardless, do not export by default. I mean it! PLEASE PLEASE PLEASE
We've been telling people not to do this for while, but standards seem to be slipping a little lately, with even quite new modules exporting things like "copy" into the callers namespace.
My suspicion is that it is because many of the older File:: module do this, and so people think that it is ok.
Your one exception might be if the most likely name is something truly odd, like "encode_rfc30042" that is pretty much NEVER going to collide with anything.
| [reply] |
Re: Binding C libraries
by frostman (Beadle) on Feb 08, 2005 at 03:43 UTC
|
Unfortunately I can't give you any practical advice since I don't know C...
But as to your last question, I think it's best to have an object-oriented interface if possible and a simple procedural interface to the most common methods.
This way you will satisfy the people writing OO programs without scaring away beginners or people in a hurry (or anyone else who prefers it procedural).
CGI.pm is one example of a very popular module that does it both ways.
(I am assuming of course that the thing you want to do can sensibly be done both OO and procedurally, which I think is implied in your question.)
| [reply] |
|
|
Not everything can be written in an object-oriented manner. The OP asked about C, which doesn't directly support the object oriented paradigm.
Generally, the design is specific to the application. Use the most suitable tool for the job ! If all you're writing is a set of list utilities, for example, no object orientation is *really* needed. In some designs, however, there really is a place for objects.
One of the most important things to keep in mind about this is that a library is better to be "stateless". This allows to write multi-threaded code with no problems. Object oriented programming in Perl (passing $self around) is stateless if done right. Writing a C library with a bunch of static objects and functions that act upon them is far from being stateless, however, and if such a thing is absolutely required don't forget to document it.
| [reply] |