SWIG is a software development tool to ease the use of C/C++ code from other programming languages. These so called 'target languages' vary enormously. The most popular being the scripting languages Python, Perl, Ruby, PHP & Tcl and the strongly typed languages, Java & C#. However, the full list of target languages includes various Scheme and Common Lisp languages as well as XML. For C++, SWIG generates the glue code so that a C++ class can be called from an automatically generated target language proxy class. SWIG is coded in C and C++.
Working with SWIG will expose the student to a wide variety programming languages and will give them the chance to gain some deep insight into C/C++ and one or more of the list of target languages. Exposure to Object Oriented programming in general will also be gained.
SWIG can parse and support most of standard C++ (1998, minor updates in 2003). However, there are numerous changes in the new C++ standard, known as C++11 (and formerly C++0x). Most of the implementation for the additional language syntax for C++0x was implemented in 2009.
The standard library in C++11 has been enhanced. New SWIG interface library files can be written to provide good wrappers for these new components in any chosen target language. Some good candidates are tuples, hash tables, fixed size arrays. A lot of the SWIG interface files for implementing the 2003 standard containers could be utilised for the additional STL components.
Students are advised to pick pieces of the standard that can then be made into sub-projects.
The interested student should have good C++ experience and ideally have been following developments in the new standard. This project will be working on the cutting edge of C++ and is rated mixed as the new standard is so big and varied so the tasks can be broken into sub-projects.
The C11 standard was published and we don't know how well SWIG will support it. The interested student would need to be familiar with C and get to know the additions to the C standard. Any missing functionality would need to be added to SWIG and documented along with examples.
The goal of this project would be to finish the work started on "gsoc2008-maciekd" and developed further on the "gsoc2012-c" branch and ensure that it's in a state good enough to be merged into SWIG master. Analysing which test cases fail would be the first step and then coming up with proposals to fix would then be needed.
C/C++ code is often documented using plain C/C++ comments within the code, or nowadays, Doxygen is pretty much the de-facto tool for documenting C++ code. Many of the target languages also have their standard way of generating documentation for the code, e.g. JavaDoc is used for Java, POD for Perl, PythonDoc for Python etc. An approach is required to parse these documentation comments within the C/C++ header files and use them to document the target language wrapper classes/functions in an easy and intuitive way.
In GSoC 2008, this idea was worked on, adding support to SWIG's parser to pick out Doxygen-format documentation comments and put them in to the parse tree, and to write out these comments in Java doc and Python doc format, translating the more common Doxygen markup.
In GSoC 2012 the implementation was improved in both areas - parsing and code comment generation. It produces useful output for Java and Python.
For GSoC 2013 development could be split to two tasks. The first one is replacing current doc parsing in SWIG with Doxygen comment parsing, and attaching Doxygen nodes to SWIG nodes.
The other task includes implementation of translation modules for other languages than Java and Pyhon. This task is much simpler, and existing code for Java and Python could be used as an example.
The interested student may decide to implement only one of the described tasks. At least a basic level of C/C++ is required and an interest in working with as many of the SWIG target languages as possible (lots of coding experience in these languages isn't required though). The student will gain an appreciation of compilers/parsers and gain an insight into a wide variety of documentation tools.
JDK 1.5 introduced annotations which is a syntax for adding meta data to Java elements such as methods, classes, parameters etc. SWIG needs a way for a user to add annotations to the SWIG generated proxy code. The implementation would be very similar to the C# attributes support currently in the C# module.
The interested student should have some knowledge of C, C++ and Java as well as a desire to learn more about these languages. This project is rated easy, and is probably too small by itself to make a suitable GSoC project, so you should either look to expand upon it, or combine it with another idea (for example, idea 7 below).
The requirement is to improve SWIG in the area of multiple inheritance support. For target languages, such as Python, which support multiple inheritance, there is a natural mapping between C++ and Python in this area and SWIG currently provides the natural wrappers in that the Python proxy class can derive from more than one base class. However, some target languages, like Java, only support deriving from a single base class. For these target languages the proxy class is only able to inherit from just one base class and so multiple inheritance is not supported. Many of these languages do actually provide a kind of multiple inheritance in that a class can derive from a single base class and multiple interfaces. The natural equivalent of an interface in C++ is an abstract base class (a class with only pure virtual methods).
The task is first to modify SWIG to recognise and classify abstract base classes. Secondly, choose one or more target language and modify to make use of this classification such that the proxy class implements the interface in the target language. The suggested target languages to improve are C# and/or Java. There is a patch which already provides some of this functionality.
The interested student must preferably have a basic level of C++ experience or alternatively some experience in Java or C#.
Scilab is a numerical computing high level language. It is pretty similar to Octave/Matlab in its syntax. In a previous GSoC, a Scilab binding has been developed. While it is almost completed, it is still in a dedicated branch. A new version of Scilab, version 6, is currently under development. This version introduces a C++ API.
The GSoC subject would be:
This would be done in collaboration with the Scilab project (also part of the GSOC 2013).
Currently SWIG's PHP backend generates a PHP module which wraps a C++ API as a set of flat functions, and also generates a .php file containing classes with methods which call these flat functions.
It would be simpler and more efficient to create objects using PHP's Zend API instead.
Skills: Some familiarity with PHP is required. Knowledge of C++ useful. Prior experience of SWIG and especially its PHP backend is a bonus.
SWIG now supports mapping C++ namespaces into namespaces or equivalent concepts in the target languages using the %nspace directive, but currently this is only implemented for C# and Java.
This project would be to expand this to support as many target languages as possible.
SWIG needs to be able to parse C/C++ expressions for constants, default parameter values, and template parameters. Currently there are some limitations to what is supported.
This goal of this project would be to eliminate these limitations.
"Template template parameter support is flaky and could be sorted out."
A chance to get involved in some advanced C++ features.
The goal is to provide native C/C++ access for Windows Phone/WinRT either via PInvoke by enhancing the C# target language or by picking completing the COM wrappers.
Supporting nested C structs and nested C++ classes has been done in the C++ parser. Initial support has been put in place for C# and Java is underway. Other target languages need this support added in.
Add Cython support, that is, output Cython code instead of C/C++ and Python when wrapping C/C++ libraries. Either a new module would be needed or the Python module adapted to for Cython.
Since Python 3.2, Python has a common ABI (PEP 384). This can be used to create Python binary extensions that can work with all successors of Python 3.2 with no recompilation. The exact same binary extension can be used, which is very interesting for deployment.
The macro Py_LIMITED_API should be defined in order to use the common ABI. Adding in this support should probably be done in conjunction with the -builtin and -py3 options.
First suggested on the swig-user mailing list by Didier Trosset on 23 May 2013.
We encourage students to suggest their own ideas. The flexibility and power of SWIG is immense as it will parse C/C++ and has the machinery to easily generate any code. Additionally, there are a number of feature requests which could be implemented. Interested students should email the community on the swig-user mailing list where we can give more information.
If you have an idea of suitable scope for GSoC which you'd like to see an idea listed on this page, please chat to us on IRC, see below. Bonus points if you're willing and able to mentor it.
Students are strongly encouraged to discuss their ideas on the SWIG mailing lists in order to be considered for acceptance. Alternatively, you should find some of the developers on IRC at #swig-gsoc on irc.freenode.net.