- Boost-announce - lists.preview.boost.org

Futures - Reviews Needed (January 5, 2009)
by Tom Brinkman 30 Dec '08

30 Dec '08

Futures Join the review and discussion starting January 5, 2009. I need commitments for reviews from threading experts on the two Futures library candidates. Braddock Gaskill - http://braddock.com/~braddock/future Anthony Williams - http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp Early comments are welcome.

1 0

BoostCon 2009: Call for Participation
by Hartmut Kaiser 13 Dec '08

13 Dec '08

Hi all, before we all relax into the holidays I wanted to remind you all about next year's Boost Conference in Aspen, CO, USA, May 3-9. Even if all important dates are listed in the attached Call for Participation, I'll list them here once again: Proposals for submissions due: January 10th 2009. Proposals acceptances sent (tentative program available): February 10th, 2009 Fully scheduled program available: March 1st, 2009 Session materials due: April 1st 2009. IOW, you might want to use some of your free time during the next weeks to think about a possible contribution. It really doesn't take much time to come up with a short abstract! Let's make sure BoostCon 2009 will be a major C++ event! Happy holidays! Regards Hartmut Program Committee Chair BoostCon 2009

1 0

[boost] [review][constrained_value] Review of Constrained Value Library begins today
by Jeff Garland 01 Dec '08

01 Dec '08

Hi all, The review of the Robert Kawulak's Constrained Value library begins today December 1, 2008, and will end on December 10th -- I will be the review manager. Please post reviews to the developer list. Here's the library synopsis: The Boost Constrained Value library contains class templates useful for creating constrained objects. A simple example is an object representing an hour of a day, for which only integers from the range [0, 23] are valid values. bounded_int<int, 0, 23>::type hour; hour = 20; // OK hour = 26; // exception! Behavior in case of assignment of an invalid value can be customized. The library has a policy-based design to allow for flexibility in defining constraints and behavior in case of assignment of invalid values. Policies may be configured at compile-time for maximum efficiency or may be changeable at runtime if such dynamic functionality is needed. The library can be downloaded from the here: http://rk.go.pl/f/constrained_value.zip The documentation is also available online here: http://rk.go.pl/r/constrained_value --------------------------------------------------- Please state in your review, whether you think the library should be accepted as a Boost library. Additionally, please consider the following aspects in your review of the library: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Thanks, Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost

1 0

[Review] UUID library (mini-)review ends today, November 30rd
by Hartmut Kaiser 01 Dec '08

01 Dec '08

Hi all, the review of Andy Tompkins' UUID library ends today, November 30th. Nevertheless, it's still possible to submit a review for at least a week, as I'm not going to have time for the analysis of the review before Christmas. Thanks to all of you who submitted a review. Regards Hartmut Review Manager

1 0

Review Wizard Report for November 2008
by Ronald Garcia 25 Nov '08

25 Nov '08

============================================== Review Wizard Status Report for November 2008 ============================================== News ==== May 7 - Scope Exit Library Accepted - Awaiting SVN May 17 - Egg Library Rejected August 14 - Boost 1.36 Released New Libraries: Accumulators, Exception, Units, Unordered Containers August 27 - Finite State Machines Rejected September 10 - Data Flow Signals Rejected September 30 - Phoenix Accepted Conditionally November 3 - Boost 1.37 Released New Library: Proto November 10 - Thread-Safe Signals Accepted - Awaiting SVN November 25 - Globally Unique Identifier Library mini-Review in progress Older Issues ============ The Quantitative Units library, accepted in April 2007 is in SVN (listed as units). The Time Series Library, accepted in August 2007, has not yet been submitted to SVN. The Switch Library, accepted provisionally in January 2008, has not yet been submitted for mini-review and full acceptance. Property Map (Fast-Track) and Graph (Fast-Track) have been removed from the review queue. The author (Andrew Sutton) intends to submit a new version of this work at a later time. A few libraries have been reviewed and accepted into boost, but have not yet appeared in SVN as far as I can tell. Could some light be shed on the status of the following libraries? Apologies if I have simply overlooked any of them: * Flyweight (Joaquin Ma Lopez Munoz) * Floating Point Utilities (Johan Rade) * Factory (Tobias Schwinger) * Forward (Tobias Schwinger) * Scope Exit (Alexander Nasonov) * Time Series (Eric Niebler) * Property Tree (Marcin Kalicinski) -- No documentation in SVN Any information on the whereabouts of these libraries would be greatly appreciated. For libraries that are still waiting to get into SVN, please get them ready and into the repository. The developers did some great work making the libraries, so don't miss the chance to share that work with others. Also notice that the review process page has been updated with a section on rights and responsibilities of library submitters. General Announcements ===================== As always, we need experienced review managers. The review queue has been growing substantially but we have had few volunteers, so manage reviews if possible and if not please make sure to watch the review schedule and participate. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants or library contributors. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "garcia at osl dot iu dot edu" and "phillips at mps dot ohio-state dot edu" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. A recent effort is trying to secure at least five people who promise to submit reviews as a precondition to starting the review period. Consider volunteering for this and even taking the time to create the review as early as possible. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report before we do that, please email Ron or John. If you're a library author and plan on submitting a library for review in the next 3-6 months, send Ron or John a short description of your library and we'll add it to the Libraries Under Construction below. We know that there are many libraries that are near completion, but we have hard time keeping track all of them. Please keep us informed about your progress. Review Queue ============ * Lexer * Boost.Range (Update) * Shifted Pointer * Logging * Futures - Williams * Futures - Gaskill * Join * Pimpl * Constrained Value * Thread Pool * Polynomial -------------------- Lexer ----- :Author: Ben Hanson :Review Manager: Eric Neibler :Download: `Boost Sandbox Vault <http://boost-consulting.com/vault/ index.php? action=downloadfile&filename=boost.lexer.zip&directory=Strings%20-% 20Text%20Processing&>`__ :Description: A programmable lexical analyser generator inspired by 'flex'. Like flex, it is programmed by the use of regular expressions and outputs a state machine as a number of DFAs utilising equivalence classes for compression. Boost.Range (Update) -------------------- :Author: Neil Groves :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?action=downloadfile&filename=range_ex.zip&directory=>`__ :Description: A significant update of the range library, including range adapters. Shifted Pointer --------------- :Author: Phil Bouchard :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?&direction=0&order=&directory=Memory>`__ :Description: Smart pointers are in general optimized for a specific resource (memory usage, CPU cycles, user friendliness, ...) depending on what the user need to make the most of. The purpose of this smart pointer is mainly to allocate the reference counter (or owner) and the object itself at the same time so that dynamic memory management is simplified thus accelerated and cheaper on the memory map. Logging ------- :Author: John Torjo :Review Manager: Gennadiy Rozental :Download: http://torjo.com/log2/ :Description: Used properly, logging is a very powerful tool. Besides aiding debugging/testing, it can also show you how your application is used. The Boost Logging Library allows just for that, supporting a lot of scenarios, ranging from very simple (dumping all to one destination), to very complex (multiple logs, some enabled/some not, levels, etc). It features a very simple and flexible interface, efficient filtering of messages, thread-safety, formatters and destinations, easy manipulation of logs, finding the best logger/filter classes based on your application's needs, you can define your own macros and much more! Futures ------- :Author: Braddock Gaskill :Review Manager: Tom Brinkman :Download: http://braddock.com/~braddock/future/ :Description: Joint review of the Futures libraries scheduled for 1/5/09-1/20/09. The goal of the boost.future library is to provide a definitive future implementation with the best features of the numerous implementations, proposals, and academic papers floating around, in the hopes to avoid multiple incompatible future implementations in libraries of related concepts (coroutines, active objects, asio, etc). This library hopes to explore the combined implementation of the best future concepts. Futures ------- :Author: Anthony Williams :Review Manager: Tom Brinkman :Download: http://www.justsoftwaresolutions.co.uk/files/ n2561_future.hpp (code) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/ n2561.html (description) :Description: Joint review of the Futures libraries scheduled for 1/5/09-1/20/09. This paper proposes a kind of return buffer that takes a value (or an exception) in one (sub-)thread and provides the value in another (controlling) thread. This buffer provides essentially two interfaces: * an interface to assign a value as class promise and * an interface to wait for, query and retrieve the value (or exception) from the buffer as classes unique_future and shared_future. While a unique_future provides move semantics where the value (or exception) can be retrieved only once, the shared_future provides copy semantics where the value can be retrieved arbitrarily often. A typical procedure for working with promises and futures looks like: * control thread creates a promise, * control thread gets associated future from promise, * control thread starts sub-thread, * sub-thread calls actual function and assigns the return value to the promise, * control thread waits for future to become ready, * control thread retrieves value from future. Also proposed is a packaged_task that wraps one callable object and provides another one that can be started in its own thread and assigns the return value (or exception) to a return buffer that can be accessed through one of the future classes. With a packaged_task a typical procedure looks like: * control thread creates a packaged_task with a callable object, * control thread gets associated future from packaged_task, * control thread starts sub-thread, which invokes the packaged_task, * packaged_task calls the callable function and assigns the return value, * control thread waits for future to become ready, * control thread retrieves value from future. Notice that we are in the unusual position of having two very different libraries with the same goal in the queue at the same time. The Review Wizards would appreciate a discussion of the best way to hold these two reviews to produce the best possible addition to Boost. Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?action=downloadfile&filename=Pimpl.zip&directory=&>`__ http://www.ddj.com/cpp/205918714 (documentation) :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Constrained Value ----------------- :Author: Robert Kawulak :Review Manager: Jeff Garland :Download: http://rk.go.pl/f/constrained_value.zip :Description: Review scheduled for 12/1/08-12/10/08 The Boost Constrained Value library contains class templates useful for creating constrained objects. A simple example is an object representing an hour of a day, for which only integers from the range [0, 23] are valid values: :: bounded_int<int, 0, 23>::type hour; hour = 20; // OK hour = 26; // exception! Behavior in case of assignment of an invalid value can be customized. For instance, instead of throwing an exception as in the example above, the value may be adjusted to meet the constraint: :: wrapping_int<int, 0, 255>::type buffer_index; buffer_index = 257; // OK: wraps the value to fit in the range assert( buffer_index == 1 ); The library doesn't focus only on bounded objects as in the examples above -- virtually any constraint can be imposed by using a predicate: :: // constraint (a predicate) struct is_odd { bool operator () (int i) const { return (i % 2) != 0; } }; :: // and the usage is as simple as: constrained<int, is_odd> odd_int = 1; odd_int += 2; // OK ++odd_int; // exception! The library has a policy-based design to allow for flexibility in defining constraints and behavior in case of assignment of invalid values. Policies may be configured at compile-time for maximum efficiency or may be changeable at runtime if such dynamic functionality is needed. Thread Pool ----------- :Author: Oliver Kowalke :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boostpro.com/vault/ index.php?action=downloadfile&filename=boost-threadpool. 2.tar.gz&directory=Concurrent%20Programming>`__ :Description: The library provides: - thread creation policies: determines the managemnt of worker threads - fixed set of threads in pool - create workerthreads on demand (depending on context) - let worker threads ime out after certain idle time - channel policies: manages access to queued tasks - bounded channel with high and low watermark for queuing tasks - unbounded channel with unlimited numer of queued tasks - rendezvous syncron hand-over between producer and consumer threads - queueing policy: determines how tasks will be removed from channel - FIFO - LIFO - priority queue (attribute assigned to task) - smart insertions and extractions (for instance remove oldest task with certain attribute by newst one) - tasks can be chained and lazy submit of taks is also supported (thanks to Braddocks future library). - returns a task object from the submit function. The task it self can be interrupted if its is cooperative (means it has some interruption points in its code -> ``this_thread::interruption_point()`` ). Polynomial ---------- :Author: Pawel Kieliszczyk :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boostpro.com/vault/ index.php? action=downloadfile&filename=polynomial.zip&directory=>`__ :Description: The library was written to enable fast and faithful polynomial manupulation. It provides: - main arithmetic operators (+, -, * using FFT, /, %), - gcd, - different methods of evaluation (Horner Scheme, Compensated Horner Algorithm, by preconditioning), - derivatives and integrals, - interpolation, - conversions between various polynomial forms (special functions for creating Chebyshev, Hermite, Laguerre and Legendre form). Libraries under development =========================== Please let us know of any libraries you are currently developing that you intend to submit for review.

1 0

[Review] UUID library (mini-)review starts today, November 23rd
by Hartmut Kaiser 24 Nov '08

24 Nov '08

Hi all, The mini-review of Andy Tompkins UUID library starts today, November 23rd 2008, and will end on November 30th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! The library can be downloaded from the vault here (it's the file uuid_v13.zip in the topmost directory): http://tinyurl.com/6xx28b The initial review of the UUID library ended with a provisional acceptance (read here: http://article.gmane.org/gmane.comp.lib.boost.user/27774/) This mini review is meant to allow for a final decision after looking at the changed parts of the library. Here is a list of things fixed and changed: - fixed the licensing issues revealed by the initial review - fixed the security vulnerability revealed by the initial review - renamed to uuid, moved all classes, functions, etc. to namespace boost::uuids - implemented sha1 hash function (thus no license problem) - new class basic_uuid_generator to create random-based uuids. The random number generator is no longer hard coded. It can use any random number generator, default is boost::mt19937 - implemented a good seed function for random number generators - all functions are now reentrant, all classes are as thread safe as an int and the library is no longer dependent on Boost.Thread --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

1 0

[signals2][review] signals2 review results
by Stjepan Rajko 20 Nov '08

20 Nov '08

** signals2 review results ** I am pleased to announce that the signals2 library by Frank Mori Hess is accepted into boost, pending some conditions outlined below are met. I would like to thank the author for his work on this library, and for his very responsive participation in the review. I would also like to thank Franz Alt, Jean-Cristophe Benoist, Vicente Botet, Fabio Fracassi, Johan Råde, Ravikiran Rajagopal, Andrew Webber, and Jesse Williamson for submitting reviews, and Terry Golubiewski, Michael Marcin, and Hansjörg for additional comments regarding the library. There were 5 votes cast for the acceptance of this library, and 3 against accepting the library at this time. The reviewers that were against immediate inclusion of signals2 suggested that the library should be accepted when several stated problems are addressed adequately. Overall, the library was regarded as a much needed thread-safe successor of Boost.Signals. Those that have tried switching from Boost.Signals to signals2 have found the switch rather painless (at least in the cases that don't involve the Boost.Signals trackable interface), and some reported using signals2 and/or its previous versions in production code. Some additional improvements that were mentioned are an automatic connection management system based on shared_ptr, and a change of namespace (which avoids problems with QT). Additionally, many requests were made for improvements in the documentation, as well as some improvements in thread-related testing and some possible changes to the interface. Frank has addressed many of the issues in the review, and in many cases offered concrete steps to address the problems. Following is an overview of the most prominent issues that were raised. These issues must be addressed before this library is included in the trunk and subsequent releases: ** Boost.Signals -> signals2 transition ** There needs to be a concrete plan of migration from the current version of Boost.Signals to signals2. The almost-decided-on route is to have both Boost.Signals and signals2 co-exist in Boost for a few releases, with Boost.Signals getting deprecated. From reading the reviews, it looks like no one has a problem with this, so it seems like it's just a matter of an agreement between the library maintainers that gets posted in the documentation / on the lists. The bigger part of the problem is to make sure that users of Boost.Signals can transition to signals2 as easily as possible. Given the reports so far, this process is indeed easy, with the biggest exception being the removal of the trackable interface in signals2 (which was removed because it is not thread-safe). Frank has indicated that he will put it back into the library and make it available for single-threaded signals as a way to ease porting for Boost.Signals users, which sounds like a great step. My biggest concern here is that the signals2 interface is "gotten right" (with respect to compatibility with Boost.Signals) by the time it is included in Boost, so that porting is both easy and a fixed target. Given how easy people have found porting their code so far, it looks like restoring the trackable interface might is all that is needed. I would discourage any further breaking changes to the interface (one thing mentioned was dropping some of the template parameters), but I also recognize the opportunity to improve the interface in response to the review. Any signals2 interface changes that significantly break compatibility with Boost.Signals should be considered very carefully (even if Boost.Signals will stay on for a while), and if possible, counterbalanced by a compatibility layer put in to ease the transition for Boost.Signals users. ** Documentation ** Pretty much all reviewers noted the documentation as lacking with regard to thread-safety aspects of signals2 and other added functionality. Frank has clarified many of the questions that came up during the review, and outlined a plan of integrating the requested information into the documentation. Specific items are outlined in my notes at the end of this mail. ** Tests ** Some reviewers also noted a lack of tests for thread-related functionality. I agree that whatever can be reasonably tested should be tested. Frank has suggested he will try to adapt some of the Boost.Thread tests where adequate. As stated, the above issues should be addressed before moving the signals2 library to the boost trunk. I don't anticipate significant problems because: * the trackable interface has already been brought into signals2 at one point in the past * all documentation related questions have been clarified during the review, and Frank's suggestions for updating the documentation were agreeable * Boost.Thread tests should provide some insight into how signals2 thread-safety could be more thoroughly tested. Also, several reports have been made of signals2 already being successfully used in production settings, which speaks to its reliability. I strongly suggest that Frank make an announcement when the changes are completed, so that those interested can make sure that their concerns have been adequately addressed. Given Frank's record as a very responsive maintainer of this library in the past, and his commitment towards the peer-review process (he insisted on having this library reviewed even though it could have technically been included with Doug Gregor's approval as an upgrade to Boost.Signals), and considering that one of the reviewers has already offered to review changes to the library, I anticipate that a de facto mini-review of the library will happen at that point even though I am not requiring one formally. Finally, below are some notes on suggested changes I extracted while reading through all of the reviews. Square brackets contain initials of some of the reviewers that mentioned the issue, and double curly braces my personal comments. This is by no means a record of everything that has been mentioned, but perhaps the author will find it useful while making the post-review changes. To be clear, the below changes are not required for the inclusion of signals2 into the boost trunk, except as they pertain to the required changes outlined above. -- Implementation -- ---- * source code could be formatted more clearly [FA] * address efficiency problems where signals2 is significantly slower than signals [FA] {{ while efficiency is important, and ideally signals2 efficiency for single-threaded use cases converges to that of Boost.Signals, this is one area where improvements can painlessly continue to happen after the integration of signals2 into the trunk (as long as they don't require interface changes), so I don't consider this a priority at this point }} * clean macro names used with Boost.Preprocessor [VB] -- Interface -- ---- * portable syntax - either establish that the syntax works (and on what compilers) or consider deprecating [JW] * use Boost.Parameter for signal template parameters due to so the user doesn't have to specify default template parameters. [VB][FA] {{ if there are any arguments against changing the signal class template to use Boost.Parameter directly, you could still provide a metafunction that uses Boost.Parameter to provide the signal type. This would allow, e.g.: signal_type<void(int, int), mutex_type<signals2::mutex> >::type my_signal; }} * use template parameters such as single_threaded or multi_threaded instead of the mutex type. [vb] {{ it should be possible to allow the Mutex parameter to be either a mutex class or a special (or policy) type that maps to a particular mutex }} {{ this suggestion was given in conjunction to a proposal for allowing external locking mechanisms, but it seems like external locking should be possible with what the library already offers - perhaps an example of this would be useful }} -- Documentation -- * update code examples in tutorial to contain fixes already present in the package [JW] {{ if you aren't already, consider using the quickbook import facility to keep the compiled code snippets and docs in sync }} * FAQ should be mentioned earlier / information in the FAQ should be more visible [JW][VB] * while the Beginner/Intermediate/Advanced designations have been found useful [FA], the tutorial has also been found readable beginning to end without much use for the designations [JW] * clarify call ordering between grouped / ungrouped slots [JW] * clarify optional_last_value [JW] [AW] * clarify the way slot::track works [VB][JW] {{ the documentation says we "pass the shared_ptr to the slot via its slot::track method before connecting", but the clarification given to Jesse Williamson also explains that the *pointer* held by shared_ptr is passed to the slot_type constructor. This seems easy to trip over - some syntactic sugar that avoids using the shared_ptr twice in the expression in two different ways might be helpful }} * offer / point to some documentation on, and provide an example for postconstructible / predestructable / deconstruct_ptr. [FA][AW][VB][FF] * document / provide example for extended_slot_type [FA] [FF] * expand the documentation of various mutexes that can be used and their properties [VB] also in regards with co-use with Boost.Thread [FF] {{ I can find the mutexes explained in the reference documentation, but an overview at the tutorial level would be nice }} * expand discussion on thread-safety: ** how exactly is signals2 thread-safe? [JB][RR] ** explain behavior in various threading circumstances [JB] * mention the benefits of the new connection management based on shared_ptr over old trackable interface (e.g., allowing non-intrusive use with 3rd party classes) [FF] * consider making the portable syntax examples less prominent [FF] -- Testing -- * add multi-threading tests [JB] * include performance tests [VB] Again, thanks and congratulations to Frank Mori Hess, and thanks to all of the reviewers. Kind regards, Stjepan

1 0

Boostcon 2009 call for sessions
by dan marsden 09 Nov '08

09 Nov '08

3rd annual Boost Conference 2009 Aspen CO, USA, May 3-9, 2009, www.boostcon.com ---------------------------------------------------------------------------- Call for participation ---------------------- Promising to be the main face-to-face event for all things Boost (www.boost.org) BoostCon'09 opens the door to your C++ future. From using the Boost libraries to writing and maintaining them, from evangelizing to deploying Boost within your organization, from infrastructure and process to vision and mission, and from TR1 to TR2 and the new C++0x Standard, BoostCon brings together the sessions, the colleagues, and the inspiration to support your work with C++ and Boost in particular for the next year. To reflect the breadth of the Boost community, the conference includes sessions aimed at two constituencies: Boost end-users and hard-core Boost library and tool developers. The program fosters interaction and engagement within and across those two groups, with an emphasis on hands-on, participatory sessions. Session topics -------------- * Topics of interest include, but are not restricted to, the following: * General tutorial sessions introducing one or more Boost libraries * In-depth sessions on using specific libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * C++0x and how it will change life for users and library writers * TR1 and TR2 * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Other topics likely to be of great interest to Boost users and Developers. Interactive and collaborative sessions are encouraged, as this is the nature of both the on-line Boost community and the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. Session formats --------------- Presentations ............. Presentations focus on a practitioner's ideas and experience with anything relevant to Boost and Boost users. Panels ...... Panels feature three or four people presenting their ideas and experiences relating to Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials ......... Tutorials are sessions at which instructors teach conference participants specific Boost-relevant skills. Workshops ......... Workshops provide an active arena for advancements in Boost-relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner Presentations ............................. These were introduced at BoostCon 2008, and were a great success. They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems boost libraries. Tool Vendors Presentations .......................... We actively encourage tool vendors and ISP's to submit proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. Submitting a proposal --------------------- Standard Sessions are 90 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 90 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other * A paragraph or two describing the topic covered, suitable for the conference web site * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half-day, full day * Alternate lengths, if you are willing to make adjustments: 10-20 minute lightning-talks, 45 minutes, 90 minutes, half-day, full day * Audience: users, developers, both * Level: basic, intermediate, advanced * A biography, suitable for the conference web site * Your contact information (will not be made public) Submission details ------------------ All submissions have to be done through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=boostcon09. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted papers will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the BoostCon CD handed out to attendees. For general information on the BoostCon 2009 paper submission or the scope of technical papers solicited, please refer to the conference website at www.boostcon.com. For any other questions about the submission process or paper format, please contact the Program Committee at boostcon09(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to BoostCon. Important dates --------------- Proposals for submissions due: January 10th 2009. Proposals acceptances sent (tentative program available): February 10th, 2009 Fully scheduled program available: March 1st, 2009 Session materials due: April 1st 2009. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) David Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

Boost 1.37.0 Release Notice
by Beman Dawes 03 Nov '08

03 Nov '08

Boost 1.37.0 has been released and is available from SourceForge. See http://sourceforge.net/projects/boost/ This release includes one new library: Proto: Expression template library and compiler construction toolkit for domain-specific embedded languages, from Eric Niebler. Updated libraries include Asio, Circular Buffer, Dynamic Bitset, Hash, Interprocess, Intrusive, Math Type, Traits, and Unordered. The release managers were Beman Dawes, Daniel James, Eric Niebler, and Rene Rivera. The web site should be updated soon to reflect the new release. If you can't wait, see http://beta.boost.org now! --Beman Dawes

1 0

[signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st
by Stjepan Rajko 01 Nov '08

01 Nov '08

Hello all, The review for the Signals2 library (formerly known as thread_safe_signals) submitted by Frank Mori Hess begins today (Nov 1st) and is scheduled to end on Nov 10th. I would like to thank Franz Alt, Terry Golubiewski, Doug Gregor, Ravikiran Rajagopal and Andrew Webber for making this review possible by committing to reviewing the library. How to submit a review: -------- As usual, EVERYONE is welcome to participate in the review discussions and to submit a review. I strongly encourage participation from reviewers that would examine the library from a purely user standpoint (commenting on the interface and / or the documentation), as well as reviewers that would be willing to look into the details of the implementation (i.e., you don't have to focus on both). Here are some questions you might want to answer in your review (feel free to skip those that don't apply to your analysis): * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Please submit your review either to the list or privately to me by the end of the review period. If you send me a review privately I will forward it to the list so the review can be discussed. If you would prefer me to forward your review anonymously (with your name removed) please indicate that in your e-mail. If you are a first time reviewer, here is some more information to get you started: * http://www.boost.org/community/reviews.html has more information on the review process * the review officially takes place on both the boost dev and boost-user lists, but typically more of the discussion happens on the boost dev list * if you want to get a feel for past reviews, you can find them in the archives (see http://www.boost.org/community/groups.html) - the past review dates are on the review schedule (http://www.boost.org/community/review_schedule.html) Typically, there is a period of discussion between the reviewers and the author, with official reviews coming in towards the tail end of the review period. About the library: -------- * The library can be downloaded from: http://www.boostpro.com/vault/index.php?&directory=thread_safe_signals (latest version is signals2-2008-10-08.zip) * Documentation is also available online: http://www.comedi.org/projects/signals2/libs/signals2/doc/html/index.html * A synopsis: The Boost.Signals2 library (formerly known as thread_safe_signals) is an implementation of a managed signals and slots system. Signals represent callbacks with multiple targets, and are also called publishers or events in similar systems. Signals are connected to some set of slots, which are callback receivers (also called event targets or subscribers), which are called when the signal is "emitted." Signals and slots are managed, in that signals and slots (or, more properly, objects that occur as part of the slots) can track connections and are capable of automatically disconnecting signal/slot connections when either is destroyed. This enables the user to make signal/slot connections without expending a great effort to manage the lifetimes of those connections with regard to the lifetimes of all objects involved. When signals are connected to multiple slots, there is a question regarding the relationship between the return values of the slots and the return value of the signals. Boost.Signals2 allows the user to specify the manner in which multiple return values are combined. * Relationship to Boost.Signals: This is a thread-safe variant of the original Boost.Signals library. There have been some changes to the interface to support thread-safety, mostly with respect to automatic connection management. The following thread offers some more details on the differences between the two implementations, as well as a plan of a phased replacement of Boost.Signals should Signals2 be accepted: http://tinyurl.com/4sqau3 [nabble] The Signals2 FAQ also covers some differences: http://tinyurl.com/576gl6 Kind regards, Stjepan (review manager)

1 0