Google Summer of Code 2014

Welcome to the Boost C++ Libraries' home page for Google Summer of Code (GSoC). This page provides information about student projects, proposal submission templates, advice on writing good proposals, and links to information on getting started writing with Boost.

This year Boost is looking to fund work on a number of different kinds of proposals:

• toolkit-like extensions to existing libraries,
• finishing or extending sandbox libraries,
• new data structures and algorithms, and
• multiple competing proposals for the same project.

For projects involving new or experimental libraries, the process of getting source code "Boost-branded" can take much longer than a single summer. In many cases, it can take much longer than a single year. Even if a library is accepted, there is an expectation that the original author will continue to maintain it. Building a library as part of Boost can easily entail a multi-year commitment. For this reason, we are willing to consider multi-year GSoC projects. However, prospective students must limit the scope of their work to a single summer. We may invite the most successful students to re-apply in 2015.

Requirements

Students must submit a proposal. A template for the proposal can be found here here. Hints for writing a good proposal can be found here.

We strongly suggest that students interested in developing a proposal for Boost discuss their ideas on the mailing list in order to help refine the requirements and goals. Students who actively discuss projects on the mailing list are also ranked before those that do not.

Self-contained standalone GSoC Projects

The following projects have been suggested by potential mentors. If the descriptions of these projects seem a little vague... Well, that's intentional. We are looking for students to develop requirements for their proposals by doing initial background research on the topic, and interacting with the community on the mailing list to help identify expectations.

Projects from previous years can be found here. There are still a number of interesting projects found in these pages.

Boost.Math Generalized Hypergeometric Functions

Boost.Math http://www.boost.org/doc/libs/1_55_0/libs/math/doc/html/index.html is a large well-established Boost library, but new and useful mathematical functions can always be added.

Generalized hypergeometric functions are convergent power series that have rational coefficients.

​http://en.wikipedia.org/wiki/Generalized_hypergeometric_function

Hypergeometric functions are remarkably versatile because many well-known functions of pure and applied mathematics are special cases of hypergeometric functions. These include various mathematical constants, elementary transcendental functions, Bessel functions, the incomplete gamma function, confluent hypergemetric functions, generalized Legendre functions, and (infinitely) many more.

Even though the theory of hypergeometric functions is well-established, very few programs or libraries support these fascinating and versatile functions.

In this project, we will implement fast, accurate calculations of certain generalized hypergeometric functions and establish convergent parameter ranges for these. We will write them with generic templates, as is suitable for Boost.Math.

Our work will make use of many numerical methods for special functions, including expansions in Chebyshev polynomials, rational approximations, Pade approximations, Taylor series, asymptotic series, and others.

The main goals of the project are:

• Investigate calculation methods for hypergeometric_0f1, 1f0, 1f1, 1f2, 2f1.
• Evaluate regions of parameter convergence for these.
• Ensure that calculations are fast and accurate for all built-in types and some multiple-precision types.
• Optional: Add support generalized Legendre functions of type-I to Boost.Math.
• Optional: Replace certain internal calculations within Boost.Math with hypergeometric functions.

This project requires a passion for serious mathematical programming and at least some knowledge of advanced C++. In particular, we will be using templates which Boost.Math makes much use of to support not only built-in float, double and long double but also multiple-precision types. It will be helpful to have experience using Boost libraries, including Boost.Test, and a rudimentary knowledge of GIT.

A preliminary investigation carried out for this project can be found here: ​https://github.com/boostorg/multiprecision/blob/develop/example/hypergeometric_luke_algorithms.cpp

In this investigation, multiple-precision hypergeometric functions were calculated with three-term recursion series of Chebyshev polynomials. If this code leaves you utterly terrified, then this project is not for you. But if it only frightens you a little bit, yet also piques your interest, and if you have a passion for numerical programming, then you are the right candidate for this project!

If you would like to demonstrate your skills, use the functions in the file in the link above for multiple-precision calculations of cylindrical Bessel functions (i.e., cyl_bessel_j). Hint: Consider the relation between hypergeometric_0f1 and cyl_bessel_j. Use the multiple-precision data type cpp_dec_float_50 from Boost.Multiprecision. Discuss convergence properties and document some run-time characteristics. You can use any platform, Linux, Mac or Microsoft with your IDE of choice, perhaps Visual Studio, Eclipse, Code Blocks, or Net Beans.

This project will by mentored by Christopher Kormanyos, and also supported by Paul Bristow and John Maddock regarding algorithmic expertise and Boost infrastructure.

Boost.AFIO (proposed) Improvements to async file i/o and closure execution engine

Proposed Boost.AFIO is a linear scalable, batch, chainable, asynchronous closure execution engine with an almost wait free implementation (it is wait free if the CPU supports memory transactions) extending Boost.ASIO and Boost.Thread specialised as a portable asynchronous file i/o implementation library. Proposed Boost.AFIO was successfully ported to Boost during GSoC 2013 by Paul Kirth, and entered the Boost peer review queue in October 2013. If it passes peer review, AFIO is thought likely to be the first C++ 11 only library to enter Boost. You can see AFIO's Boost documentation at ​https://ci.nedprod.com/job/Boost.AFIO%20Build%20Documentation/Boost.AFIO_Documentation and its current continuous integration buildbot status and source code at ​https://github.com/BoostGSoC/boost.afio (scroll to bottom for present CI buildbot status). You are encouraged to read the AFIO documentation extensively before writing a GSoC proposal, and ask questions on boost-dev where needed.

There are some interesting work items extending AFIO which would be ideal for a summer student project:

1. POSIX async i/o support is limited to a threadpooled emulation. Proper support for Linux's kaio and POSIX's aio_* interfaces would be great. Note that these APIs are extremely tricky to get working right across all POSIX platforms, especially OS X. To propose this project the submitter would need developer access to Microsoft Windows, Linux, FreeBSD and preferably OS X. Difficulty level of this item is medium.

2. Portable fast file locking which works across network shares, but can still utilise shared memory when possible. To propose this project the submitter would need developer access to Microsoft Windows, Linux, FreeBSD/OS X. Difficulty level of this item is medium.

3. Fast, scalable portable directory contents change monitoring. It should be able to monitor a 1M entry directory experiencing 1% entry changes per second without using a shocking amount of RAM. To propose this project the submitter would need developer access to Microsoft Windows, Linux, FreeBSD/OS X. Difficulty level of this item is hard, there are professional software engineers with over a decade of experience who would take several attempts to get this right (luckily you have an experienced mentor to help you!).

4. AFIO is also a closure execution engine, and API conformance with the current ​Executors and Schedulers proposal before the ISO C++ standards committee would be useful. I would also suggest bundling into this work item Fibers support such that both cooperative and preemptive threading models are supported. Difficulty level of this item is medium for those very comfortable with programming in asynchronous frameworks like WinRT, otherwise it is hard and very hard for some types of programmers who are not "async wired".

5. By the time GSoC begins AFIO ought to have a finished async batch hash engine which provides SHA256, CityHash and SpookyHash. Additional hash implementations would be very useful. Before you think you can copy and paste in existing hash implementations, be aware that AFIO requires you to completely rewrite them into batch SIMD (SSE2, AVX and preferably ARM NEON) and implement considerable C++ metaprogramming to tell the compiler how to optimally assemble the implementation. Difficulty level of this item is hard, but very suitable for low level type programmers who like writing in assembly but also like C++ metaprogramming. The batch hash engine can be seen at ​https://github.com/BoostGSoC/boost.afio/blob/content_hashing_merge/boost/afio/hash_engine.hpp, and an example of the SIMD programming you'd have to do at ​https://github.com/BoostGSoC/boost.afio/blob/content_hashing_merge/boost/afio/detail/impl/hashes/4-sha256/sha256-neon.c.

This project could be mentored by Niall Douglas (​http://www.nedprod.com/), and possibly Hartmut Kaiser (​https://www.cct.lsu.edu/~hkaiser/). Due to limits on free time especially as I am also Boost GSoC admin this year, I (Niall) would only be able to mentor one student this summer, and I generally provide a programming test based on AFIO to students whose have submitted proposals to ensure that their coding ability is minimally sufficient to be able to attempt a GSoC. Benefits for the student of a successful GSoC in this area are many: high performance async programming experience is very desirable in the marketplace right now, and getting your name attached to authorship of a Boost library is a shining bright light on a resume which will stand to your career for years to come. You will gain bleeding edge experience programming exclusively in C++11 across the main toolsets of Visual Studio, GCC and clang AND writing portable code for the main operating system platforms of Microsoft Windows, Linux, and BSD/OS X - again, all very desirable skills to have in the marketplace. For those of you looking at a career in computer science research, and depending on the success of your outcomes, you may even be able to pass peer review to present your work at the C++ Now conference held annually in May. Good luck with your GSoC applications!

Boost.odeint

Boost.odeint ​http://www.odeint.com is a library devoted to finding numerical solutions of ordinary differential equations (ODEs). It is developed in a generic way using Template Metaprogramming which leads to extraordinary high flexibility at top performance. It is widely used in academic and industrial projects. Boost.odeint has been a Google Summer of Code project in 2011 ​http://google-melange.appspot.com/gsoc/project/google/gsoc2011/mulansky/14001 and we would like again to see students involved in the development of this numerical library. Therefore, we offer the two following projects:

Implicit Routines

The current focus of odeint is on explicit routines, namely the Runge-Kutta schemes or the multi-step methods. However, we would like to expand odeint by adding implicit routines in the same flexible manner. Implicit routines are important when dealing with stiff systems, but also ensure stability in some cases of discretized partial differential equations (PDEs). At the moment, odeint provides an implicit Euler and Rosenbrock algorithm, but the implementation is restricted to Boost.uBlas. As one of the main objectives of odeint is to provide highly flexible algorithms, we want to change this implementation to have a greater flexibility and interchangeability similar to that of the explicit routines. This project would not only require pure coding, but first also a considerable amount of design work.

• Develop a design on how the requirements on implicit routines can be modularized
• Implement a prototype showing the usability of the design
• Change the existing routines to the new design
• Implement other backends (MTL, eigen,...) to demonstrate the flexibility
• Provide examples and documentation
• (Add more implicit routines, if time permits)

This project does not only require profound knowledge on C++ and generic programming, but we would also like to see some experience on numerical algorithms and solving ODEs, if possible.

The project will be mentored by Karsten Ahnert and Mario Mulansky.

• ​http://en.wikipedia.org/wiki/Numerical_methods_for_ordinary_differential_equations
• ​http://en.wikipedia.org/wiki/Runge%E2%80%93Kutta_methods
• ​http://en.wikipedia.org/wiki/Explicit_and_implicit_methods

Boost.Functional / Invoke

Provide a boost::invoke function implementation of the c++11 definition of INVOKE for c++11 and C++03 compilers based on the interface defined in [1]. [2] could be taken in consideration.

Provide a boost::invoker template class that stores a function and its arguments and make it a nullary function. This can be used in Boost.Thread to implement C++11 compatible boost::thread construction, boost::async, boost::future:then(). This class is quite similar to the result of the function bind, but it doesn't use boost::ref.

Make use of invocation_traits (see[3] in Boost.Thread to make it possible an More perfect forwarding in functions as boost::thread construction, boost::async, boost::future:then().

This has already been fully implemented by Agustin Berge as part of HPX [4]:

This project could be mentored by Vicente J. Botet Escriba

[1] ​http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3727.html

[2] ​https://github.com/boostorg/thread/tree/develop/include/boost/thread/detail/invoke.hpp

[3] ​http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3866.html

[4] ​https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/util/invoke.hpp.

Boost.Functional / Monads

Monads are invading the C++ planet. optional/maybe, expected/either, future can be seen all as monads. Containers/Sequences are as well monads and in particular smart pointers can be seen as well as monads.

Having a common interface for all these monads would help to built on top of monads algorithms. E.g. overloading the usual operators, operations such as when_all/when_any (see {3}) could be defined for 'compatible' monads.

The link Monads in C++ [1] show a way to do it that seems interesting. [2] is a whole library that contains an implementation.

The project would be implemented on C++11 compilers, using any C++11 feature that could make the library easier to prototype.

Some performance measures comparing the higher level monads interface and the hand written solution should be provided.

Functional programming background is a must as well as understanding Monads in Haskell. Some knowledge of template meta-programming in C++ is needed. [1] ​http://yapb-soc.blogspot.fr/2012/10/monads-in-c.html

[2] ​https://github.com/splinterofchaos/Pure

[3] ​http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3857.pdf

In addition to provide the common interface to some of the Boost monads, the project could add the State monad.

This project could be mentored by Vicente J. Botet Escriba, with support from Niall Douglas (proposed AFIO may have a partially implemented experimental monadic generic then() implementation by the time GSoC begins).

Boost.Thread / Work-Stealing-Thread-Pool

Provide a boost::work_stealing_thread_pool class scheduling arbitrary functions based on the interface defined in [1]. [2] should be taken in consideration. The implementation would need a thread safe queue that allows to steel works efficiently. The first implementation would address only C++11 compilers supporting thread_local variables. A C++98 implementation would be welcome.

[3] present a clear survey on the problem domain.

HPX (see [4]) contains several work-stealing implementations.

[1] ​https://github.com/boostorg/thread/tree/develop/include/boost/thread/executors

[2] ​http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3562.pdf

[3] ​http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3872.pdf

[4] ​https://github.com/STEllAR-GROUP/hpx

This project could be mentored by Vicente J. Botet Escriba and possibly Hartmut Kaiser.

Boost.Thread / Scheduler-Executor

Provide boost::scheduled_executor implementations base on the C++ proposal [1] and the draft implementation in [2].

[1] ​http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3562.pdf

[2] ​https://github.com/boostorg/thread/tree/develop/include/boost/thread/executors

This project could be mentored by Vicente J. Botet Escriba and possibly Hartmut Kaiser.

Boost.Thread / Parallel algorithms

Base on [1] and [2] but adding an Executor parameter, add parallel_xxx algorithm in Boost.Thread.

[1] ​http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf

[2] ​http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3554.pdf

This project could be mentored by Vicente J. Botet Escriba and possibly Hartmut Kaiser.

Boost.Fixed-Point

A fixed-point number is a finite-precision approximation of a real number with a fixed number of digits before the radix point and a fixed number of digits after the radix point. Fixed-point numbers are used in diverse technical fields ranging from optimized microcontroller programming through high-performance financial calculations and beyond. In microcontroller programming, fixed-point numbers can provide floating-point representations with near-integer performance even if a dedicated floating-point unit is not available. This is key because it allows the use of sophisticated mathematical calculations including transcendental functions, special functions, digital filters, power regulation methods, etc. in the regime of cost-sensitive devices and rounding-intolerant environments.

In this project, we will provide an implementation of a fixed-point library based on ​http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html. The core work involves developing a series of templates and template specializations that embody the fixed-point numbers in various precision ranges. A prototype with a different interface is available at ​https://svn.boost.org/svn/boost/sandbox/fixed_point. We will concentrate on radix-2 fixed-point representations. We will attempt to cover a wide range of precision and performance, ranging from tiny 8-bit and 16-bit fixed-point representations all the way up to 32-bit, 64-bit and beyond. As with all Boost projects, testing and documentation are mandatory and we will provide a rich test suite and legible documentation as we progress.

This project requires a high degree of knowledge of advanced C++ methods such as template programming, generic numeric programming, and the ability to represent data structures in an abstract form.

If you are interested in this project, investigate the reference templates in ​https://svn.boost.org/svn/boost/sandbox/fixed_point. A simplified fixed-point representation targeting cost-sensitive microcontroller applications can be found in ​https://github.com/ckormanyos/real-time-cpp/tree/master/ref_app/src/math/fixed_point, and it is described in detail in ​http://www.springer.com/computer/communication+networks/book/978-3-642-34687-3. If you would like to display your skills and understanding of the project domain, try to use any of these reference applications in a real-world calculation. Describe your calculation and the results you obtain.

[1] ​http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html

[2] ​https://svn.boost.org/svn/boost/sandbox/fixed_point

[3] ​https://github.com/ckormanyos/real-time-cpp/tree/master/ref_app/src/math/fixed_point

[4] ​http://www.springer.com/computer/communication+networks/book/978-3-642-34687-3

This project will be mentored by Christopher Kormanyos with technical and algorithmic support from Vicente J. Botet Escriba.

Boost.Chrono / Date

Provide an implementation of a Date library based on [1] and taking in account the original design as defined in [2] and the performance study in [3]. It would be welcome to integrate the algorithms defined in [4].

A prototype with a different interface is available also at [5].

[1] ​http://github.com/viboes/chrono_date/libs/date/doc/date.qbk

[2] ​http://home.roadrunner.com/~hinnant/bloomington/date.html

[3] ​http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3344.pdf

[4] ​http://home.roadrunner.com/~hinnant/date_algorithms.html

[5] ​http://github.com/viboes/chrono_date

This project could be mentored by Vicente J. Botet Escriba

Boost.Exception / Stack-Unwinding

Make a real Boost library the Stack-Unwinding library [1] from Evgeny Panasyuk ready for review.

[1] ​https://github.com/panaseleus/stack_unwinding#d-style-scope-guardsactions

This project could be mentored by ?.

Boost.Pipelines

Provide boost::pipelines implementations base on the C++ Pipelines proposal [1] and the Google implementation in [2]

[1] ​http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3534.html

[2] ​https://code.google.com/p/google-concurrency-library/source/browse/include/pipeline.h

This project could be mentored by Vicente J. Botet Escriba

Boost.XML

Define a set of XML APIs (DOM, SAX, XMLReader, etc.) for C++.

There are a couple of good XML libraries available with C and C++ interfaces. So the focus shouldn't be yet another XML library implementation, but rather, a clean and robust set of APIs, with bindings to the existing implementations. A good starting point for the API is [1], as well as [2]. The latter also already provides multiple backends (such as [3], [4], [5]).

[1] ​https://github.com/stefanseefeld/boost.xml

[2] ​https://github.com/jezhiggins/arabica/

[3] ​http://www.xmlsoft.org/

[4] ​http://xerces.apache.org/xerces-c/

[5] ​http://msdn.microsoft.com/en-us/data/bb190600.aspx

This project could be mentored by Stefan Seefeld

Boost+Travis CI integration and Android cross-compilation

This is project for improvements of Boost's infrastructure. This project can be beaked down to the following parts:

• Adding automated ​Travis CI testing scripts to all the Boost libraries (Knowledge of Ruby language would be an advantage).
• Finishing the work with running the Boost's ​regression tests on Android.
• Write scripts for regression testing and cross-compilation on remote devices and emulators (RaspberyPI/Qemu).
• Writing a documentation about cross-compiling and running regression test of Boost libraries for different targets.

This project requires basic knowledge of scripting languages and a lot of patience. Project could be interesting not only for programmers, but also for system administrators that have the courage to dig into the world of cross-compilations, auto-testings, and build scripts.

This project could be mentored by Antony Polukhin and Niall Douglas

Boost.Document

Library for integration with spreadsheet applications Excel/LibreOfficeCalc/OpenOfficeCalc and other ​office programs. Idea is to unify APIs of different Office suits and provide a clear header only library that is capable of doing simple tasks with office documents (creation, pdf exporting, file format changes, data extraction and cells manipulations). Such library is essential for banking software, CRMs and many other programs.

This project requires a good C++ knowledge, generic programming. Experience with Office's API would be an advantage.

This project could be mentored by Antony Polukhin

Boost.Binaries

Library that provides instruments for a binary to self control. This can be useful for protection against viruses and other attacks; protect programs against reverse engineering; can help post-process binaries (find how a compiled function looks like, put something into the binary after compilation, compute and store checksums of binary).

Basic functionality would be:

• marking part of code at compilation
• reserving space for after-compilation data
• checksumming/encrypting/decrypting marked code at runtime

This project requires a good C++ knowledge. Knowledge of assembly languages would be an advantage.

This project could be mentored by Antony Polukhin

Moving Boost to Boost.Move

There a re a lot of Boost libraries that don't support move semantics. It would be nice if one student propose to adapt the some of the existing libraries.

The idea is to use Boost.Move so that an emulation is provided for compilers not supporting rvalue references.

Some of the libraries (let me know if I'm wrong are). My priority is given between [], lower numbers means higher priority. Of course others would have others priorities:

C++11

• [0] Tuple or * Fusion/tuple (it seems that it support or will support c++11 move semantics but don't use Boost.Move)
• [0] Bind
• [1] Function
• [2] SmartPtr
• [8] Array ?

Accepted for C++14

• [5] optional

Having an active proposal for C++1y

• [3] Heaps
• [6] Any
• [7] Variant

Other

• [4] LockFree
• [9] Parameters
• [10] Signals?

Please help me to complete this list.

Adding constexpr and noexcept would be welcome also.

This project could be mentored by Vicente J. Botet Escriba

Bjam clone based on the Boost libraries

• Write a parser for the most important rules (exe, lib and so on) based on Boost.Spirit
• Use the parser's actions to create a dependency tree based on Boost.Graph
• Attach Python functions to the nodes in the dependency tree based on Boost.Python
• Implement Python functions for one toolset (like g++)

The project promises a lot of variety as different Boost libraries have to be used. It's also an opportunity to get familiar with various Boost libraries. As it can be broken down into tasks it shouldn't be that difficult to make a realistic plan for a summer project.

For more information have a look at ​https://github.com/boostcon/2011_presentations/raw/master/mon/Boost.Build.pdf and ​http://www.highscore.de/cpp/boostbuild/.

Possible mentor: Boris Schaeling

Boost.uBLAS a library for linear algebra procedures

Ideas of GSOC projects for 2014:

• Matrix multiplication with operator* and compile-time optimization depending on the nature of the matrix
• fixed-sized matrices known at compile-time
• integration of the notion of row and column vector, making M2 = V*M1 a valid (or not) operation at compile-time
• Matrix/vector views for interoperability: I think this is ultra critical because now ublas is monolithic in the sense that you have to use it everywhere you manipulate data. This would really help into letting people for example have a list of vectors (they are plotting) and ublas working on top of that to do for example transformations
• Incorporate some critical bindings (i.e. mumps bindings which is currently probably the most efficient smp and distributed open source linalg solver), and other bindings to Intel, AMD, etc... libraries. Many examples already exists (Boost.numeric.bindings, ViennaCL, etc...)
• Matlab binding and Matlab integration as well as interoperability with R, python, ...
• Optimization and inversion algorithms !!!!

Mentor: David Bellot (david.bellot[at]gmail.com)

Ideas

If after reading all of the standalone project ideas above you are finding that none excites you, we have collected below a series of smaller work items none of which alone would be big enough to make up a full GSoC, but which could be combined to form a very valuable GSoC indeed. The following would be excellent start points for students to propose projects themselves (see below on how to do this). While these ideas are by far not as concrete as projects in the list above, they give students an idea what else they can work on within Boost. They also give students a chance to propose exactly the kind of project they'd like to work on instead of picking one from the predefined projects from above.

Students interested in proposing a mix of the below work items should propose their mix on the Boost mailing list using the instructions below. We will then figure out a suitable mentor for you.

How to propose a mix of the below work items on the Boost mailing list

Please do not simply arrive on the list and ask "I want to do GSoC Idea item no X because I don't want to do one of the predesigned GSoC projects on the list. Give me a mentor." as you will likely be ignored as a probable time waster. If you are to propose your own GSoC project, it must be of equivalent quality to the precanned GSoC project proposals written by mentors already on the ideas page, and by "equivalent", we really do mean equivalent i.e. very high. This is why mentors take the time to write project proposals for you, because for mentors who are domain experts in their field it is easier to write a high quality GSoC proposal likely to pass peer review and Google's own proposal review than for students who are not domain experts. If you are still really sure you want to invest the very considerable work to propose your own project, do the following before writing to the Boost mailing list with your own proposal:

1. Research prior art i.e. provide proof in your approach email that you have researched alternative implementations in C++ and other languages of your project proposal. A list of pros and cons of those alternative implementations would be useful and show you really did study the problem.

2. Have a well designed, concrete, realistic as a summer project design based on synthesis of the prior art research. It's great to list known unknowns as far as possible. When designing, don't forget well over half the effort in writing a new Boost library goes exclusively into writing documentation and writing unit and functional testing. This is a big reason we need students to have good English, because a lot of writing Boost code is actually writing its documentation.

3. Ideally students who provide proof they have successfully written a high quality STL algorithm implementation before i.e. can supply a link to an open source copy of their work are far more likely to be well received than those students with no such proof of capability and depth of understanding just how hard writing high quality C++ code is. Be aware we don't really care what grades you received in some CS class - we want to see code you've written.

4. Failing item three, any evidence or proof demonstrating a good work ethic, and are humble and willing to learn, is always helpful. Good examples of such evidence are code commits fixing bugs in open source projects, or a history of improving documentation for open source projects, or a history of porting code to new platforms or fixing platform specific build problems - all these are excellent pieces of proof because we can verify their accuracy and look at the quality of your work.

If you can provide at least two of the above four points, your custom GSoC proposal is highly likely to be taken seriously, and you'll get plenty of feedback on what needs fixing, plus mentors will volunteer themselves. Miss all of the above factors and no one - student or otherwise - will be taken seriously, and any emails by you to the Boost developers list will probably be ignored.

With all that said, here are the smaller work items which could be combined to form a very valuable GSoC project:

Boost libraries (extending/overhauling/finishing)

• Reliable UDP (may UDT) for Boost.Asio
• USB for Boost.Asio
• Extension/reflection library (​http://boost-extension.redshoelace.com/docs/boost/extension/index.html)
• std::packaged_task scheduler (like Intel TBB's with task stealing) for Boost.Thread. Note proposed Boost.AFIO already implements this.
• Filesystem abstraction + path cleanup (​http://thread.gmane.org/gmane.comp.lib.boost.devel/238103)
• Pipes for Boost.Iostream (and maybe Boost.Asio for named/asynchronous pipes)
• Protocol implementations for Boost.Asio
• Factories for Boost.Flyweight (​http://tinyurl.com/bktkc3s)
• Replace all uses of CAS spinlocks in all Boost libraries with memory transactions via BOOST_BEGIN_MEMORY_TRANSACTION. See ​https://svn.boost.org/trac/boost/ticket/9615.

Algorithms

• Radix sort
• Approximate string matching
• Full text search
• Near Duplicate Detection (shingling)
• Parallel algorithms (sort, for_each)
• Algorithms for gpgpu
• Kinetic scrolling

Data strutures

• Trie data structure, extending the work done during GSoC 2013.
• B-tree data structure, extending the work previously done by Beman Dawes.
• Concurrent containers (unordered_map, unordered_set, vector, forward_list)
• Slim string (as opposed to the fat std::string interface, maybe immutable, maybe policy based)

Media

• Hardware graphics (OpenGL/OpenGL ES/DirectX abstraction)
• Audio library (OpenAL/FMOD/etc)
• Video processing library (gil for video)

Games

• Physics library (ODE/Havok/PhysX/etc abstraction)
• Input library (like DirectInput/XInput)
• Ranking algorithms (elo/TrueSkill)

Databases

• Relational database library (​http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Relational_Database_Access)
• Document database library (couchdb/mongodb/etc)
• Spatial indexes

Math

• Geometry library (convince the developers to submit Eigen 3 to Boost)
• Investigate exporting multiple-precision types to Python via Boost.Python and interoperability with "symbolic python". See: ​http://sympy.org/en/index.html

Memory

• Memcache library
• Memswap algorithm

File formats

• JSON parsing libary
• XML library

Communication

• Channel library (​http://channel.sourceforge.net/)
• RPC

GUI

• GUI library

C++ "extensions"

• Type switch library (​http://tinyurl.com/n3449)

Hardware

• CPUID

Potential mentors in some general topic or field

• Hartmut Kaiser, parallelism, concurrency. Perhaps porting items from HPX to Boost.
• Kyle Lutz, proposed Boost.Compute (on these work items ​https://github.com/kylelutz/compute/issues).
• John M. Dlugosz, unstated topics.
• Tim Blechmann, concurrency.