![[Home]](/boost.png)
Google Summer Of Code 2007Google Summer Of Code 2007Tips for the students
Non-students: if you have an interesting idea for a Boost project for GSoC 2007 and you want to give it to the public, please edit this page and write it down! You can copy and paste the template listed as the first entry. Don't forget to update the table of contents, too.
Introduction: Introduce the main concepts around the project: Theoretical preliminaries, preexisting Boost libraries used (if any), important concepts, problems/needs the project will try to solve/satisfy.
Goal: Concise statement of the overall goal of the project. Refine this initial statement to include: project deliverables (code, docs, testing), required/suggested methodology, standards of quality, possible goal extensions beyond the main objective.
Requirements: List the requirements and level of expertise you estimate the student will have to meet: Required level of C++, specific areas of the language (STL, templates, locales, whatever), level of familiarity with Boost and particular Boost libraries, development/documentation/testing tools, mathematical/algorithmic background, other desirable skills.
Other sections: If you have more to say about the project that doesn't fit in the proposed sections of this template, feel free to add other sections at will. Oh, and don't forget to separate each entry with a horizontal line, entered at the edit box as ----
Introduction: Extend Boost.Regex to support recursive regular expressions, so for example (?r1) would match sub-expression $1 recursively, note this is not the same as a backreference. A typical example would be matching arbitrarily nested {}'s using something like: (\{((?r1)|.)*\}). A second often requested feature to add is named sub-expressions, so that a sub-expression match stored in a match_results can be accessed via a predefined name (a string) rather than by index.
Goal: Identify changes needed to Boost.Regex to support the new features, develop patches to code, tests and docs to support the idiom. Much of the work involves creating tests to adequately test the prototype code. The changes should be relatively easy to make, so there is the opportunity for the student to identify and work on his/her own ideas for Boost.Regex in the second half of the project. These could include more speculative changes to Regex, or external tools/examples built upon regular expressions.
Requirements: Good knowledge of templates, the STL and Boost. Most important is the ability to think through complex program logic: regex state machine transitions will stretch your brain, and recursion only makes it worse!
Other sections: If the initial work proceeds smoothly then there should be the opportunity towards the end of this project to extend it in whatever way the student sees as desirable. Applications should therefore include the students own ideas on how they see the project progressing.
Introduction:
It is becoming more and more important for Boost to have documentation that looks and feels the same, no matter what library you are using. Having one style of documentation makes the user feel at home, and minimizes time spent learning how to navigate the docs.
However, the documentation in Boost is written in a variety of formats. Besides QuickBook, I think the two most popular is RST and plain vanilla HTML.
Goal:
Write a conversion tool that converts from RST and HMTL to QuickBook. The tool should strive to preserve as many facets of the original code (like coloring etc).
Requirements:
Basic knowledge of C++, STL is certainly required. But there is no need that this program should be written in C++ instead of, say, Python. OTOH, it would be cool to showcase Boost when writing the program.
Suggested by Thorsten Ottosen (thorsten.ottosen@dezide.com)
Introduction: Boost has a tool called Quickbook that simplifies the generation of Docbook XML, however the tool needs better installation scripts (there is some past work in this area that needs finishing off), some more features (Indexes, mathematical formulae support, handle multiple image formats for a single graphic, correctly encode image dimentions in the output), and perhaps a website of it's own.
Goal: Identify and priorise the steps that need to be taken to make quickbook a self-contained tool suitable for general purpose documentation authoring, and work through those steps. Potentially this project could be combined with the HTML->docbook conversion project, or two students could work on separate development streams towards the same overall quickbook-improvement goal. Knowledge of quickbook's internals and the changes made to it during the project should be documented as an overview of the code, to make life easier for anyone following on after.
Requirements: Boost, STL, parsers, XML/Docbook? experience would help too, as would general HTML/css knowledge.
Introduction: asio scratches an itch that many of us has: an asynchronous networking library written using modern C++ techniques. However, it only implements TCP, UDP and SSL/TLS. What is lacking, which is also what most people need is a code for http, ftp, etc. that can be reused.
Goal: Write, using the recently accepted asio library, a library or an extension to asio that implements application level protocols such as http and ftp (bare minimum). It should employ modern C++ techniques, and should use the same paradigm as asio does. Extensive documentation should also be a must, so that users won't resort to reading header files to understand how to use the library.
Requirements: Intermediate to advanced knowledge of C++. Familiarity with standard library and asio and boost. Familiarity with application level protocols.
Possible references:
Introduction: Good cryptographic libraries are hard to find, and their documentation could be improved by leaps and bounds. The designs all vary, from being runtime based (string identification of algorithms) to compile-time based (C++ templates and the like). It would be nice if Boost provided a cryptographic library that utilises modern C++ programming techniques, and has good performance, and is extensively documented.
Goal: Write, using Boost code where necessary, a library that implements cryptographic functions and primitives, and helper functions that makes using the library easier. The library should use modern C++ design, and must be extensively documented.
Requirements: Prior experience in implementing both secure and fast cryptographic algorithms. Prior experience in writing generally secure code. Intermediate to advanced C++ programming experience, and familiarity with Boost or C++ Standard Library is preferred.
Possible references:
Introduction: An ORB/RPC system for C++ appears to be sorely lacking. It's like searching for a needle in a haystack. The only 2 ORBs/RPC systems I am aware of are ACE/TAO or ICE. However, both of them have their potential limitations. This project aims to solve them.
Goal: Write, using asio and other Boost code, an ORB/RPC implementation. It need not be related to ICE or CORBA, but some degree of similarity is preferred
Requirements: Prior experience in CORBA or ICE. Good knowledge about C++ and networking and RPCs. Should be experienced with asio.
Possible references:
Note: This project is unlikely to be approved -- it's too large and difficult for an SoC project - Jeff Garland
Introduction: Implement a "big integer" class template which supports all C++ arithmetic and boolean operators to do arbitrary precision calculations.
Goal: Code, docs and tests need to be delivered, some benchmarks against other popular big number libraries (GMP) are a plus and show where improvements are needed.
Requirements: Basic knowledge of C++ templates and a good math background is required. Familiarity with literature (Knuth's Seminumerical Algorithms) or other code on the subject is a plus.
Notes: Another class template for fixed size big integers could be implemented once the algorithms are in place which gives the compiler a better chance to optimize and which gets rid of the allocator parameter. Basic operations are relatively easy to implement. More effective algorithms for very large precision integers may be more complicated but can be added easily once the framework is done. The same goes for functions like pow(), sqrt(), etc. This can be done if the student has enough time left.
Introduction: Implement 'safe int' class template which supports all C++ arithmetic and boolean operators and will ensure client notification on all failures such as arithmetic overflow and underflow.
Goal: Platform independent code, docs and tests to Boost need to be delivered -- review within SoC? period would be a plus (only if you think it's doable).
Requirements: Basic knowledge of C++ templates and a good understanding of limits of computer computation systems. Extreme ability to focus on details.
Notes: The target here is to applications that are highlh David LeBlanc? at Microsoft created something similar a couple years back. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure01142004.asp
SafeInt and suggest might be combined with existing Boost code from date_time call constrained_value. this would allow you to define constrained range safe integers like this:
typedef SafeInt?<int, 0, 255> BufRange?;
char buf[BufRange?::max()+1];
BufRange? i = 254;
i++; //ok
i++; //out of range exception
//now it's impossible for this to be out of range:
if (buf[i] == ...
Introduction: Fixed Decimal types provide an alternative to floating point types that are superior in their calculation properties. Robert Klarer of IBM has proposed adding these types to C++ [in n2198 (pdf)] and prior papers. This work is now on track to be included in C++0x. Robert has an implementation of these types with a restrained license. This project involves implementing the n2198 interfaces in a Boost library.
Goal: Platform independent code, docs and tests to Boost need to be delivered with as much of 2198 as possible.
Requirements: Basic knowledge of C++ templates and a good understanding of limits of computer computation systems. Extreme ability to focus on details.
Notes: This project clearly involves much less 'interface design' since the interface is already defined. However there is still tricky design work to implement these types correctly. Some research on the best approaches might be required.
Introduction: Many Boost documents have (or could benefit from) simple graphs plotting some X against Y. The proposed Math Toolkit documentation provides many typical examples. But there seems no simple way of converting the output from a C++ program, for example evaluating a function like sin over a range and getting a compact scalable graphic that can easily be added to documents. There are some separate utility program that output other, less compact, formats like JPEG, but these require a separate post C++ step.
Goal: To write C++ templated functions to allow data in C++ arrays and STL containers, vector is an obvious one, to produce a file, for example, in SVG format (XML). Provide functions to allow control of axes ranges, point types and colors, line colors, axes ticks, axes labels, title, and legend. Some simple math functions will allow demonstration of the basic 2-D version viewable in the common web browsers. Floating point types (including User-defined types) should be implemented first (and include handling NaNs and infinity), but integer types (perhaps including histograms), and possibly complex types might be added later. 3-D (including a Z axis) might be added as a further extension).
Requirements: Only fairly basic C++ will be needed (but templates and floating-point essential) and arrays and STL containers. Little familiarity with Boost and particular Boost libraries is needed. Any development/documentation/testing tools, modest mathematical/algorithmic background needed to demonstrate. Demonstration programs should show use of a variety of arithmetic types and data containers and some varied generating functions, including some ill-behaved ones that result in NaNs and signed infinities. Testing should confirm compliance with W3C standards using their website tests.
Other sections: It would be nice to show that some existing QuickBook documentation (for example, Math Toolkit) can incorporate the resulting SVG files, and is much more compact than JPEG, and is portable and scalable. www.svg.org gives many useful links. A open source cross-platform program called Inkscape looks to provide, and allow test of, some SVG xml strings. Adobe provide a SVG viewer program.
Introduction: Getting help when using Boost is not as friendly an experience as it ought to be. The mailing lists, which are the main support resource, have their shortcomings: They are a high-latency medium, required subscription poses an entry barrier, however low, and the coldness of the environment don't invite the free exchange of opinions between newbie users —typically, it is only Boost authors or seasoned members that answer all the questions, which induces a modest response throughput. As for the Boost website, it is a phenomenal reservoir for static information, but it completely lacks any community orientation: again, users don't find here a place to provide feedback, do some smalltalk or freely interact with peers. Compare this rather rigid, if effective in its way, support infrastructure, with lively and thrilling developer communities like [CodeProject] or [GameDev.net]: Where do you think the most allure lies in?
Goal: Design and implement a community website for Boost. The tentative name GotBoost? is proposed for such site. GotBoost? must be a place for entry level users of Boost as well as pros, and must provide several forms of casual interaction among its members, like for instance:
Requirements: Good web design abilities and artistic orientation. Curiously enough, no actual knowledge of C++ or Boost is required, though the student is assumed to be familiar with Boost and the Boost culture. The website must be created with an open-source, free content management system (CMS). No particular CMS is mandated, but the choice should favor extensibility and ease of maintenance: [CMS Matrix] is an excellent resource for CMS comparison and can be used to make the decision.
Introduction: The Asio library, recently accepted into boost, implements a low level synchronous and asynchronous input/output stream interface, designed for scalable high performance applications. Currently it supports TCP and SSL based streams. Support for synchronous and asynchronous operations from files and other filesystem objects has been often requested, but has not been implemented yet.
Goal: Extend the asio library to support synchronous and asynchronous filesystem IO. Synchronous IO should be easy. The deliverable should at a minimum include an portable AIO implementation using a worker thread pool. Ideally the project should also include implementations capable of taking advantage of special OS support for AIO (for example overlapped IO under Win32, Posix AIO under posix compliant OS, or more specialized interfaces).
Optionally the project could also support FS readiness notification (to let an application be notified asynchronously when a file, directory or any other FS object has been added, accessed, deleted etc.). This functionality could be implemented via polling in a separate thread of through OS specific facilities.
All delivered code must be accompanied with tests and appropriate documentation. Also some usage examples would be useful.
Requirements: Intermediate to advanced knowledge of C++. Familiarity with standard library and asio and boost. Familiarity with low level APIs of different operating systems. Knowledge of asynchronous and event driven application development. Some experience in the field is a plus.
Introduction: Boost has an implementation of TR1 (the Technical Report on C++ Standard Library Extentions), but currently this lacks certain features: most requested are unordered associative containers (hash tables). This project would fill this gap.
Goal: There is already a TR1 compatible hash-table implementation in the Boost Vault. The first phase of the project would involve bringing this up to review standard, by devising some good torture tests, and providing decent documentation. The student would then be responsible for shepherding this through the Boost formal review process. Whike waiting for the review to commense, the student has an opportunity to follow their own hash table related ideas - these might include better hashing algorithms, or a closed-hash container (cf Boost.Array).
Requirements: Good documentation skills, a thorough understanding of the STL and hash containers.
Introduction: Unit testing forms a very important part of a programmers work. And of course Boost has its own unit test framework Boost.Test. However, working with unit test reports in a console is fairly limited and to some extend down right annoying.
Goal: Write a portable GUI front-end to Boost.Test. The program must use the out-put from Boost.Test to generate reports on the fly. It would be cool if the program could be minimized to the system tray and automatically hook into a unit test project when it was run.
Requirements: Basic C++ skills.
Suggested by: Thorsten Ottosen (thorsten.ottosen@dezide.com)
Introduction: The main graph class in the Graph Library is adjacency_list, which is a swiss-army knife of graph classes, and can fulfill 99% of a user's need. However, it is quite complicated to use. What we really need is a pair of graph classes, directed_graph and undirected_graph that are easy to use and cover the common use cases. The directed graph should provide fast access to both in and out edges. Both classes should be as safe as possible from invalidation: adding edges and vertices should not invalidate graph iterators or other vertex or edge descriptors. As the adjacency_list class is the most widely used component in the Graph Library, high quality replacements for it will see even more use by the C++ community.
Goals: Implement two graph classes that fulfill the Graph Library interface specifications, a directed_graph and undirected_graph.
Requirements: Solid working knowledge of C++ templates, some prior exposure to graphs and graph theory.
