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.