Anyone ever used Swig or other c++ wrapping tools? recommendations

[mouser]

Anyone ever used Swig to automatically create wrappers around C++ class?

Swig: http://www.swig.org/

I know there are some others and i'd be interested in hearing any comparisons or experiences.

[NeilS]

SWIG is pretty amazing. I've only used it with Ruby (see Screenshot Captor scripting thread), although I did use a fair chunk of its features and I was constantly impressed by how flexible it was.

One of its best features is that the C++ parser is really pretty good, so you don't have to "sanitise" your code that much for SWIG to accept it, although you'll probably always end up generating a separate interface file anyway, just to make use of some of SWIG's extra features.

It also has a really flexible "typemap" system which allows you to control how types in C++ map to your scripting language. It comes with a decent set of defaults that will cover a lot of stuff for you, but having the ability to define your own mappings is extremely useful. The last project I did with Ruby integration would have been virtually impossible without this feature. It's not particularly easy to get your head round at first, but there's enough examples and documentation to get by.

Robustness wasn't an issue either. I was using it to generate a binding from an 16,000+ line interface file (several hundred classes) which resulted in a ~120,000 line binding implementation, and never had any problems with it. In fact, the only problem I had dealing at this scale was that Visual Studio really didn't like the 120,000 line source file (even though every other text editor I tried was quite happy with it).

One thing to note about SWIG is that it's really designed to build extensions for scripting languages, and not for embedding a scripting language into a C++ program, so the instructions are kind of geared towards extending. Having said that, you can use it for embedding (which is what I was doing) and it works very well for that.

It's also worth noting that it only deals with the scripting language's view onto the C++ program, and not the other way round. You can use some of the stuff it provides to access the scripting language from C++, but you'll probably need to write some sort of C++ wrapper for the scripting language yourself. Fortunately, this is normally pretty easy and doesn't usually require anything like the code generation required for the other direction.

Documentation: I really don't want to say anything negative about SWIG's documentation, because it really is a brilliant effort and clearly a lot of work has gone into it. The problem is that SWIG is so flexible that even the best documentation is going to leave you scratching your head on occasion, and this happened to me a few times. However, I think it's fair to say that I would have been scratching my head a lot more if the documentation wasn't as good as it was. It's certainly amongst the best documentation I've seen in an open source project.

All in all, I can happily say that if I ever decide to switch from embedding Ruby to some other language, then I'll be heading straight to SWIG again.

Oh, I've also use toLua in the past for Lua integration. It was small, simple and worked pretty well, but nowhere near as flexible as SWIG (although probably more than enough for many purposes). This was quite a few years ago, so I've no idea if it's still supported, or if it's more advanced now, or what.

I also know a few people who swear by Boost Python for Python integration, although I've never had any direct experience with it, so I can't really say much more than that.

HTH.

[mouser]

i used Swig yesterday to wrap a DLL.
I have to say I was very impressed with it for the most part,
and at the same time terribly dissappointed at the lack of some mappings.

for example, if you look at their newsgroups youll see a bunch of people saying "hey can you use Swig to wrap c++ code for use in a c api" or ".. for a delphi api" or ".. for a vb.net api" and the response is usually "people have been asking for this for a year fairly regularly, it would be easy to do but no one has done it."

i may give it a try myself but it's kind of depressing that *the* wrapping tool above all others is missing some targets that would seem to me kinda obvious.  Wrapping c++ code for a plain vanilla c-interface DLL is sort of what i would consider the base case.  I don't understand why it doesn't exist.  It never ocurred to me that it wouldnt.

Of course it's not hard to get around this, by using Swig to output stuff for a dif language and stripping unnesc. stuff, and rewriting some simple stuff on the produced output, but it's annoying.

[NeilS]

You're a hard man to please, Mouser.

Yes, I can see it being disappointing for someone if it doesn't provide support for the language they want to use, but it can't support them all.

I'm a bit confused by your C DLL example though. If you want to wrap a C++ interface so that you can access it from C code, then you're talking about new C code, aren't you? What I mean by this is that you won't have an interface to the C++ code yet, so any C code which would use this interface cannot exist yet.

If that's the case, couldn't you just write a C++ DLL instead?

[mouser]

I can see how what i said wasn't all that clear.
What I meant was that I have some classes with member functions that I wasn to expose as a standard DLL.
Because class datatypes are not safe accross languages, the solution is to basically create functions for creating objects and returning void* to them, and then creating new "proxy" functions that are called and passed the pointer to the function to work on.

Essentially this is what Swig does already.  It converts class member functions to global exported functions in a DLL that each have an additional variable that takes an object pointer to operate one.

so where in C++ you would do:

Cat* mycat = new Cat();
mycat.feed();

The wrapped C DLL would look like:

void *mycat = DLL->Cat_new();
DLL->Cat_feed(mycat);

Basically I can use Swig to create these wrapper/proxy classes by selecting a target language like C# and throwing away most of what gets produced, and changing some names and stuff, but it's confusing to me that no one has written a standard C DLL output emitter for Swig.  more than confusing.

[NeilS]

I understood what you wanted it for. What I was asking was why you couldn't just write the DLL in C++ instead?

[mouser]

well the issue isnt so much what its written in, since it is actually in c++.  The actual main DLL code is in c++.

the question is just who has to write 50 helper functions for EXPORT that can be called using a c api instead of the normal member functions to access a class.  That is, the main code uses classes - but i need to be able to call it from a client that knows nothing of classes.

the exported functions have to use that proxy method above in order to be called from a non-c++ client program (or even a client using a different c++ compiler).

i could actually have written manually the c style wrapper exported functions but i wanted to use SWIG to do it for me.

[NeilS]

Ah, I think I get you now. You want the DLL to have a C API (generated from the C++) so that you can then interface to it from any language that can interface to a C API, is that right?

I thought you were just wanting a DLL that would go alongside your own app, hence my suggestion of just using C++ for both (along with a bit of "tunelling" so they could communicate).

On that note, say someone wanted to write a LauguageX client that used this DLL, wouldn't you also want some form of SWIG output that would wrap the original C++ interface into "LanguageX as tunneled through a C API", or would you just expect clients to use the C API directly? If you see what I mean?

[mouser]

yep now we are basically on the same wavelength.  i want to expose this c++ class dll to another program, not my own.

Let me sum up what Swig does, from my understanding, and this might explain better why I was so surprised.

Swing basicaly does TWO things.

1) it creats a simplified front end to call C++ class methods, and functions that accept references and pointers.
In other words, it takes a C++ interface and makes a plain C interface that doesnt use any c++ class objects, and stuff.  So it provides a wrapper interface to functions that need objects and makes them callable in a language neutral way.

2) it creates EXTRA helper code, to make it EASIER to interface this DLL from another language.

All I really was interested in is part 1, without the extra stuff stuck in their for language specific stuff.  Swig has no such thing, which is silly, so i basically build for csharp and remove extra stuff i dont need.

[NeilS]

I don't think SWIG is actually split up into two pieces like that though.

Although it does generate C wrapper code, this wrapper is not a plain C interface to the C++ interface - it's a specific set of C wrappers that map C++ to the desired scripting language. It probably needs to do it this way so that it can preserve as much of the class structure for the scripting language to use (e.g. inheritance in your C++ classes would be represented as inheritance in Ruby).

BTW, is the C# output closer to what you need because you're using the "-noproxy" flag with it?

[mouser]

im not using any flags, its just that the code is mostly clean
for example:

Code: C [Select]

1. SWIGEXPORT void * SWIGSTDCALL CSharp_new_SimpleKeyWrapper() {
2.   void * jresult ;
3.   SimpleKeyWrapper *result = 0 ;
4.  
5.   result = (SimpleKeyWrapper *)new SimpleKeyWrapper();
6.   jresult = (void *)result;
7.   return jresult;
8. }
9.  
10.  
11. SWIGEXPORT void SWIGSTDCALL CSharp_delete_SimpleKeyWrapper(void * jarg1) {
12.   SimpleKeyWrapper *arg1 = (SimpleKeyWrapper *) 0 ;
13.  
14.   arg1 = (SimpleKeyWrapper *)jarg1;
15.   delete arg1;
16.  
17. }

where SWIGEXPORT and SWIGSTDCALL are just the normal DLL exporting.

in other words, the C# target for Swig is mostly just the same wrapper you would make yourself to expose the functions.
and then it also generates a bunch of .cs modules to help access the functions, which i discard.

[NeilS]

OK, so it looks like the C# generator is kind of doing the two steps you mentioned. It can probably get away with this since it can do them in tandem, whereas it would be much harder for SWIG itself to generate a set of C functions and then have each language generator build on top of that, if that makes sense.

So does the C# output (minus the extra .cs files) do what you want, or do you still have to make a lot of changes to it? I'm just thinking that if it's close, but not quite there, it might be fairly easy to use it as the basis of a proper C output module.