Hello all, I'm (obviously) interested in joining boost as part of GSoC 2010. Apart from a repeated try of generating interest in the Boost.Matrix library I proposed last year (I'll probably post about it later), I'll share an idea of mine that has been around in my head since I was introduced to boost several years ago. It all began with the singleton pattern -- we were writing a project, and needed a singleton base class quick, hence the first place we turned to was boost. There, two surprises awaited us -- not only wasn't there a singleton library easily available, but in the boost sources there were several singleton base class implementations, few of them even exact the same. True it is that singleton implementations differ - we want to be able to sometimes control the initialization time and initialization order, we sometimes need thread safety, and sometimes not, we'd like to control how to handle creation, and how to handle referencing to a dead singleton -- obviously a bloated master-class is not the solution -- a policy based singleton template however would be. Once that came into my mind, I couldn't shake the idea of a general Boost.Patterns library. While indulging in a discussion of whether Patterns are beneficial or not isn't my goal, we must admit that they are commonly used, and several of those are already present in Boost in one form or another (signals and flyweight comes up to mind as an obvious example). Boost.Patterns would serve as a library for collecting those patterns that aren't big enough for their own library, and encompass the smaller class traits (like boost::noncopyable) too. Apart from the singleton, one obvious candidate for such a library that I'd like to code are the factory patterns, including the abstract factory pattern. A policy based implementation of those might provide a nice benefit for boost users not wanting to reinvent the wheel. Further out, there are a few more commonly used patterns that would be beneficial for a boost::patterns user. The way I see it, for the more complex solutions, some framework of base classes to be used would have to be designed, and then used between the patterns. Mind you, I'm not trying to convince anyone to the creation of a new Boost.Patterns library (although I'd really like to do that if possible), instead I'd like to ask you if there's a viable GSoC proposal in this post, one that one day might turn into a useful part of boost. -- regards, Kornel Kisielewicz http://chaosforge.org/