First, thanks for the excellent library!
I have been writing Go bindings for the C++ HEALPix library. I have been doing that by using SWIG. This is the officially-endorsed mechanism from the Go project for linking to C++ from Go.
For the most part, this was pretty straightforward. There was just one barrier that stopped me entirely and forced me to edit my local copy of HEALPix source.
src/cxx/cxxsupport/rangeset.h and src/cxx/cxxsupport/crangeset.h hold templates for rangeset and crangeset classes. In each case, the class starts with:
private:
typedef std::vector<T> rtype;
This private rtype is then used in the public method signatures const rtype &data() const and void setData (const rtype &inp).
SWIG ignores everything private about a class, so it can't make sense of this public signature. In my local copy, I removed the typedef and just used std::vector<T> verbatim (git commit) which resolved this. Once I had made that change, SWIG worked just fine.
Could this change be made to the project as well? I'd really prefer not to maintain a fork just for a little change like this, and playing well with SWIG helps for language interoperability.
Anonymous
Ach, sorry I didn't log in before posting this. I'm commenting just to subscribe, now.
OK, I think I understand the problem, although I must admit that this seems like a defect in SWIG to me. As it is, the code should be perfectly legitimate C++ (as far as I can tell, but I'm definitely not a language lawyer), and the fact that a typedef is private should not prevent SWIG from understanding what is going on here.
Would it also be an option to make the "rtype" typedef public instead of private in the two classes? That would be my preferred workaround.
Tentative fix pushed to trunk.
Thank you for the quick response.
I agree that making the typedef public should work just as well. I tested your change and it looks good.
I also agree that this is perfectly legitimate C++. Yes, this is a defect in SWIG. It's not its only defect, believe me - the typical SWIG workflow is that you write your C++ with SWIG in mind. It's actually miraculous that this was the only insurmountable problem I found.
(the
sizeChooserHelpertemplate magic indatatypes.halso gives SWIG a hard time, but I was able to work around it).Good to know it works now!
The
sizeChooserHelpermagic could go away, I think, since we can safely assume C++11 support in every compiler these days. I'm using it mostly for the integer types, which are coverd by thecstdintheader, and for floats it should be acceptable just to stay withfloatanddouble.