gmane.comp.lib.boost.announce

Two days left to save on BoostCon / C++Now! 2012

Dave Abrahams — 2012-04-11T18:47:54

Just a quick reminder to everyone that early-bird registration closes at
the end of this week.  After Friday, the price goes up by $100.  Spots
are limited and registrations have been coming in faster than in past
years.

http://cppnow.org

Cheers!

Boost 1.49.0 release notice

Beman Dawes — 2012-02-24T21:55:14

Release 1.49.0 of the Boost C++ Libraries is now available.

These open-source libraries work well with the C++ Standard Library,
and are usable across a broad spectrum of applications. The Boost
license encourages both commercial and non-commercial use.

This release contains one new library (Heap) and numerous enhancements
and bug fixes for existing libraries. For details, including download
links, see http://www.boost.org/users/news/version_1_49_0

You can also download directly from SourceForge:
http://sourceforge.net/projects/boost/files/boost/1.49.0/

To install this release on your system, see
http://www.boost.org/doc/libs/release/more/getting_started/index.html

Thanks,

--The Boost release team

     Beman Dawes
     Daniel James
     Eric Niebler
     Rene Rivera
     Vladimir Prus
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

[PREDEF] Review for the Boost.Predef library byRene Riviera

Joel Falcou — 2012-02-18T14:08:35

The review of BOOST.PREDEF by Rene Riviera is scheduled between Monday, 
February 20th to February 29th.

================
Contents & Scope
================
BOOST.PREDEF defines a set of compiler, architecture, operating system, 
and library version numbers from the information it can gather of C++ 
predefined macros or those defined in generally available headers. The 
idea for this library grew out of a proposal to extend the Boost Config 
library to provide more, and consistent, information than the feature 
definitions it supports. What follows is an edited version of that brief 
proposal.

===============
How to get it ?
===============
Sources and documentation can be retrieved from http://tinyurl.com/73n6a3k

================
Writing a Review
================
The reviews and all comments should be submitted to the developers list, 
and the email should have "[PREDEF] Review" at the beginning of the 
subject line to make sure it's not missed.
Please explicitly state in your review whether the library should be 
accepted.

The general review checklist:

     - 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

[boost] [context] Boost.Context library accepted

Giovanni Piero Deretta — 2012-01-29T17:15:17

Hi All,

The mini-review of the boost.context library from Oliver Kowalke ended
two weeks ago. After a slow start, three reviews were eventually
submitted, all positive. For a mini-review, I think this is enough
and, as the review manager, I'm happy to announce that Boost.Context
is accepted as an official boost library. Congratulations to Oliver
for this achievement and thanks for submitting an useful library to
Boost.

Most of the review discussions were around the quality of the
documentation and some misunderstanding of some details of the
library. While the documentation has greatly improved since the first
review, I think that it can be still improved. I encourage Oliver to
seek the help of some native English speaker to help copy edit the
docs.

Finally I would like to thanks everybody that participated in the
review discussions and in particular those that submitted reviews.

regards,

[1.49.0] Beta 1 available

Beman Dawes — 2012-01-28T14:01:29

Boost release 1.49.0 beta 1 is now available from SourceForge

See http://sourceforge.net/projects/boost/files/

This release contains a new library, Boost.Heap priority queues,
and numerous enhancements and bug fixes for existing libraries.

For details of what's in the release, see
http://beta.boost.org/users/news/version_1_49_0. Note that the links
to files on this web page are for the final release - use the
SourceForge link above to get the beta files.

Please download the beta, give it a try, and report any problems you encounter.

Thanks,

Vote Boost Up for SourceForge Project of the Month

Dave Abrahams — 2012-01-19T00:28:00

Folks,

I was just informed that Boost is a top contender for SourceForge's
February Project Of The Month. The vote is happening on TwtPoll, here:
http://twtpoll.com/7vt4lq

It's pretty close, so if you could vote Boost up, it could be good for
our profile and our future.

Thanks!

[C++ Now! 2012] Deadline extension: Call forSubmissions, new deadline is January 20th, 2012

Hartmut Kaiser — 2012-01-10T16:51:42

INAUGURAL C++ NOW! CONFERENCE 2012
Aspen CO, USA, May 14-18, 2012, www.cppnow.org

CALL FOR SUBMISSIONS

We invite you to submit session proposals to the Inaugural C++ Now!
Conference: C++Now! 2012 (Aspen CO, USA, May 14 - 18, 2012).

Based on the successful traditions of 5 years of BoostCon, which was
the main face-to-face event for all things C++ and Boost
(www.boost.org), C++Now! 2012 will present leading speakers from
the whole C++ community. The conference name is changing to C++
Now! to reflect the current value of the language, the focus on its
new state (from the new Standard), and the need to continually look
to the future so the language remains useful to the C++ community.

The focus of this conference will be the new C++11 language Standard
and as usual Boost: what's new in C++, its Standard library, and in
the Boost libraries, how to write and maintain them, how to
evangelize or to deploy Boost within your organization. The new C++
Standard, but also the infrastructure and process of Boost, its
vision and mission - no matter what you are interested in, it all
comes together in the C++Now! sessions. Meet the colleagues, and
feel the inspiration to support your work with C++ and Boost for the
next year.

The C++ Now! Conference is dedicated to discussion and education
about C++, an open and free language and standard.  Our Conference
will focus on discussion and education about open source software
usage and developments in the C++ developer and user community.

To reflect the breadth of the C++ and Boost communities, the
conference includes sessions aimed at three constituencies: C++ and
Boost end-users, hard-core Boost library and tool developers, and
researchers pushing the boundaries of computation. The program
fosters interaction and engagement within and across those groups,
with an emphasis on hands-on, participatory sessions.

As a multi-paradigm language, C++ is a melting pot where the most
compelling ideas from other programming communities are blended
in powerful ways.  Historically, some of the most popular sessions at
C++Now! have highlighted these concepts, from DSLs to functional
programming to transactional memory and more.  Bring your C#,
Python, Ruby or Haskell influences to bear in an environment that will
broaden their exposure.

IMPORTANT DATES
New proposal submissions due: January 20th, 2012. UPDATED!
Proposals decisions sent (tentative program): February 17th, 2012.
Fully scheduled program available: February 25th, 2012.
Session materials due: April 15th, 2012.

BEST PRESENTATION AWARDS

We know how much effort it takes to prepare talks for our conference.
For this reason we will award the best presentations in the following
categories: Best Presentation, Best Short Presentation, Best Tutorial,
and Best Workshop. The awards will be given based on the audience's
voting. Each award will include the author's name listed on the cover
of the C++Now! website for that year and a plaque containing all the
C++Now! conference information.

SESSION TOPICS

Topics of interest include, but are not restricted to, the following:
*    C++11 and how it changes life for users and library writers
*    General tutorial sessions on C++11, the C++11 Standardslibrary,
     and one or more Boost libraries
*    In-depth sessions on using specific Boost libraries
*    Case studies on using Boost
*    Experts panels
*    Advanced sessions on implementation techniques used within Boost
     libraries
*    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
*    Software development tools and their application to C++ and or
     Boost
*    Other topics likely to be of great interest to Boost users and
     developers

Interactive and collaborative sessions are encouraged, as this is 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 C++11, Boost
and
                  users.
Panels            Panels feature three or four people presenting their
                  ideas and experiences relating to C++11 and 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 skills relevant to
                  C++11 and Boost.
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   These were introduced at BoostCon 2008, and were a
                  great Presentations 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 in Boost libraries.
Tool Vendors      We actively encourage tool vendors and ISP's to
                  submit presentations 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 60 minutes. You may submit a proposal for
fractions or multiples of 90-minutes. Fractional proposals will be
grouped into 60 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 short-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 should be made through the EasyChair conference
management system: http://www.easychair.org/conferences/?conf=cppnow2012.
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 (but are not required) 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 proposals 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 C++Now! website and will be available
to attendees.

For general information on the C++Now! 2012 paper submission or
the scope of technical papers solicited, please refer to the
conference
website at www.cppnow.org. For any other questions about the
submission process or paper format, please contact the Program
Committee at cppnow2012< at >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 C++ Now!.

Hartmut Kaiser, email: hartmut.kaiser< at >gmail.com (Program Committee
Chair)
Dave Abrahams, email: dave< at >boostpro.com (Conference Chair)

On behalf of the conference organizers



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

Boost Review Wizard Report for January 2012

Ronald Garcia — 2012-01-10T12:24:22

==============================================
Review Wizard Status Report for January 2012
==============================================

News
====


1. Type Traits Library Extensions Accepted

2. AutoIndex Tool Accepted

3. Heaps Library Accepted

4. Assign v2 Library Rejected

5. Type Traits Introspection Library Accepted

6. Lockfree Library Accepted

7. Algorithm Library Accepted

8. Atomic Library Accepted

9. Local Library Accepted

10. Context Mini-review Ongoing 


Open Issues
===========


The following libraries have been reviewed and await reports from their
review managers:

* Conversion - reviewed August 2011; review manager: Gordon Woodhull.

The following libraries have been accepted to Boost, but have not yet
been submitted to SVN:

* Constrained Value - accepted September 2010; author: Robert Kawulak
* GIL.IO - accepted January 2011; author: Christian Henning.
* Atomic - accepted July 2011; author Helge Bahmann
* Lockfree - accepted August 2011; author: Tim Blechmann.
* Algorithm - accepted December 2011; author: Marshall Clow


The following libraries have been accepted and submitted to SVN, but
have not yet appeared in a release:

* Heaps - accepted June 2011; author: Tim Blechmann.
* Type Traits Introspection  - accepted August 2011; author: Edward Diener.


The following libraries have been accepted provisionally to Boost, but
have not been submitted for mini-review and full acceptance:

* Log - accepted provisionally March 2010; author: Andrey Semashev.
* Endian - accepted provisionally November 2011; author: Beman Dawes.


After repeated failed attempts to contact the author, the following
library has been marked as Orphaned.

* Switch library, accepted provisionally January 2008 author: Steven Watanabe.


General Announcements
=====================

As always, we need experienced review managers.  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, including library contributors, infrastructure
contributors, and other mailing list participants with a substantial
track record of constructive participation. If you can serve as review
manager for any of them, email Ron Garcia or John Phillips, "rxg at cs
dot cmu dot edu" and "phillips at pacific dot 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.  If you are interested in reviewing a library but
won't have time during the review period, you can always prepare your
review ahead of time.  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.

The review schedule is an unordered list of the libraries awaiting
review. As such, any library on the schedule can be reviewed once the
developer is ready, a review manager has been secured, and 
the manager, developer, and wizards agree on a date 
to schedule the review.


Review Schedule
===============

* Join (M)
* Pimpl (M)
* Sorting (M)
* Quaternions, Vectors, Matrices (M)
* Variadic Macro Data (M)
* Block Pointer (M)
* Network (M)
* Singularity (M)
* Predef (M)


``(M)`` marks libraries that need review managers.

--------------------




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 Vault <http://www.boost-consulting.com/vault/index.php?action=downloadfile&amp;filename=Pimpl.zip&amp;directory=&amp;>`__
           | 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.


Sorting
-------
:Author: Steven Ross

:Review Manager: Needed

:Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&amp;filename=algorithm_sorting.zip>`__

:Description:

 A grouping of 3 templated hybrid radix/comparison-based sorting
 algorithms that provide superior worst-case and average-case
 performance to std::sort: integer_sort, which sorts fixed-size data
 types that support a rightshift (default of >>) and a comparison
 (default of <) operator.   float_sort, which sorts standard
 floating-point numbers by safely casting them to integers.
 string_sort, which sorts variable-length data types, and is optimized
 for 8-bit character strings.

 All 3 algorithms have O(n(k/s + s)) runtime where k is the number of
 bits in the data type and s is a constant, and limited memory overhead
 (in the kB for realistic inputs).   In testing, integer_sort varies
 from 35% faster to 2X as fast as std::sort, depending on processor,
 compiler optimizations, and data distribution.   float_sort is roughly
 70% faster than std::sort.   string_sort is roughly 2X
 as fast as std::sort.


Quaternions, Vectors, Matrices
------------------------------
:Author: Emil Dotchevski
:Review Manager: Needed

:Download: http://www.revergestudios.com/boost-qvm/

:Description: QVM defines a set of generic functions and
    operator overloads for working with quaternions, vectors and matrices
    of static size. The library also defines vector and matrix data types,
    however it allows users to introduce their own types by specializing
    the q_traits, v_traits and m_traits templates.

Variadic Macro Data
-------------------
:Author: Edward Diener
:Review Manager: Needed

:Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/variadic_macro_data/>`__

:Description:
  The variadic_macro_data library adds support and functionality for
  variadic macros to Boost as well as integrating variadic macros with
  the Boost PP library without changing the latter library in any way.


Block Pointer
-------------
:Author: Phil Bouchard
:Review Manager: Needed

:Download: `Boost Sandbox <https://svn.boost.org/svn/boost/sandbox/block_ptr/>`__
:Description: Deterministic memory manager of constant complexity capable of
  handling cyclic collections.


Network
-------
:Author: Dean Michael Berris
:Review Manager: Needed

:Download: http://cplusplus-soup.com/2011/04/18/cpp-netlib-0-9-0-released/

:Description: This is a library that provides application layer
  protocol support using modern C++ techniques. It is light-weight,
  fast, cross-platform and is intended to be as easy to configure as
  possible.



Singularity
-----------
:Author: Ben Robinson

:Review Manager: Needed

:Download: https://github.com/icaretaker/Singularity

:Description: The Singularity Design Pattern allows you to restrict
  any class to a single instance. Unlike the infamous Singleton,
  Singularity gives you direct control over the lifetime of the object,
  does not require you to grant global access to the object, nor does it
  limit you to the default constructor for that object.



Predef
------
:Author: Rene Rivera

:Review Manager: Needed

:Download: http://tinyurl.com/73n6a3k

:Description: The Predef library implements two simple tasks:

  1. Definition of a single version number macro to provide consistent
  version number at the preprocessor level.

  2. A collection of detected definitions for compilers, standard
  libraries, architectures, operating systems, and languages.

  Unlike the Boost Config Library it doesn't define language features
  and capabilities. But only defines presence of detected compilation
  context. Documentation and downloads are available in the sandbox..



Libraries under development
===========================

See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction
for a current listing of libraries under development.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

[boost] [review] Boost.Context mini-review startstoday, January 2nd

Giovanni Piero Deretta — 2012-01-02T02:45:16

Hi all,

we will start a new year of Boost reviews with a one week mini-review
of the Boost.Context library of Oliver Kowalke. The review period
starts today January 2nd and ends January 11.

Please use [context review] as prefix of your post. Reviewers are
strongly encouraged to send their reviews to the boost development
mailing list as this is the I follow more assiduously.

Please note that Boost.Context was already reviewed and conditionally
accepted last May, so we are not voting for acceptance. Instead, this
mini-review is to discuss whether the library meets the conditions on
acceptance that were listed by Vicente Botet, the review manager at
that time. You'll find the whole list at the end of this email.

Since the end of the original review, Oliver has spent a large amount
of time on a partial rewrite of the library and both me and Oliver
decided to schedule this review only after we determined that all
issues had been addressed or at least considered.

In your review please state whether the acceptance conditions have
been addressed satisfactorily.

----------------------------------------------------------------------------------

About the library:

Boost.Context is a foundational library that provides a sort of
cooperative multitasking on a single thread. By providing an
abstraction of the current execution state in the current thread,
including the stack (with local variables) and stack pointer, all
registers and CPU flags, and the instruction pointer, a context
instance represents a specific point in the application's execution
path. This is useful for building higher-level abstractions, like
coroutines and fibers.

----------------------------------------------------------------------------------

Useful Links:

documentation: http://ok73.ok.funpic.de/boost/libs/context/doc/html/

library: git://github.com/olk/boost.context.git

----------------------------------------------------------------------------------


Point to be addressed before the mini review:

Design
1. Separation of the context class in two interface:
- A C-like interface that defines a POD struct that is memcpy-able and
that can be implemented either using platform libraries, as ucontext,
fibers or directly using assembler when a robust implementation is
available. The context swap implementation don't need to save the
signals as ucontext does. The following is just for illustrations
purposes.

struct boost_context;
typedef void boost_context_fn_t(intptr_t);

extern "C" void boost_context_make(boost_context* ctx,
boost_context_fn_t * f, intptr_t p, ...);
extern "C" void boost_context_swap(boost_context* from, boost_context
const* to);
extern "C" intptr_t boost_context_destroy( boost_context* fc);

boost_context_make is a merge of get_context with make_context + some
fields assignations.

"A user will have lower expectations from such a low level API and at
the same time will give more freedom for other people to implement on
top of it higher abstractions as Boost.Corutines, Boost.Fibers ..."

- A non-copiable but movable safe context class on top of the low
level C-like interface, that will provide modern and efficient C++
interface, that is usable by a user in a safe way.

The safe context class would just be one of the client of the C-like
interface, other library authors could either use the underlying
C-like API directly or the class context depending on wether they need
the speed or safety.

* The context class will not be templated any more, and the use of
type erasure will ensure that.
* The constructor will accept any C++ callable, function pointers, functors, ...
* At this high level interface, the function provided by the user
could throw exceptions, and the library must wrap the user function
and needs to store the exception raised and provide an interface to
retrieve them.

2. The stack implementation must ensure that the stack is unwound
before it is destroyed. A stack should only be safely deallocated if
either has been completely unwound or if it doesn't own any resources.

A basic stack without protection seems mandatory.

For debug purposes it has been required to provide some stack usage
functions that allow to know the max size used for example.

Implementation
3. The assembler implementation on Windows must be disallowed if the
ABI bug reported by Holger is confirmed. As far as Windows provides a
fiber implementation that is as efficient as the assembler one, the
assembler implementation is not mandatory and the user of the provided
Windows fiber is a preferable choice.

4. Most of the 'throw' statements in the context class should actually
be asserts.

5. The provided stack should be used to store any context parameters
as far as no major impediment is found during the implementation. This
will avoid further allocations on the safe context class.

Documentation
6. The documentation is very minimalist and should be expanded with a
discussion on context switching and use cases. Take care of all the
grammar/spelling improvements suggested by the reviewers (It will be
great if Jeffrey could review the documentation before the
mini-review). Some user land examples should be provided (why not the
yield example).

7. The concept of (Movable) Stack must be clearly defined, as it is
done in the standard, using expression requirements with semantic
constraints.

8. The assembler implementation should be carefully documented, so
others could maintain the code and add other implementations if
needed.

9. Some performance measure should be added. Providing the number of
cycles on each implemented platform would be nice.

Build system

10. The default build on a platform must work (It must be ABI
compatible with the underlying platform) and take care of the specific
features. Of course, the build needs to support cross compiling, so
the user should be able to override the default values.

Others points that are not required but that can make the library more
usable or efficient:

1. The assembler implementations could be simplified if the context
itself was represented as a single pointer to the top of the stack.
This would save some instructions to move the source address from the
stack return address to the context struct and back.

2. Instead of supporting a 'fc_link' a-la ucontext, have the callback
function return a new context (it is void now). 'fc_link' is useful
only on some limited cases (usually when you have an external
scheduler managing your contexts), while the having the callback
return the 'next continuation' has more applications (note that
fc_link can be implemented easily in term of the continuation
returning variant, but the reverse is harder). This will be very
useful, for example, to implement some kind of 'exit_to' functionality
(unwind the stack and restore another context), a key piece for safe
context destruction.

3. Give to boost_context_swap the ability to exchange a parameter with the
other context:

boost_context_parm_t boost_context_swap( boost_context * ofc,
boost_context const*
nfc, boost_context_parm_t parm)

where boost_context_parm_t is either

union boost_context_parm_t {
void * ptr;
int int_;
};

or simply intptr_t;

boost_context_swap saves the current context in ocf and restores the
context ncf as usual; additionally, if ofc was 'captured' on a call to
boost_context_swap, this call will return the value of parm on the
original context. This extra parameter is equivalent to the second
parameter of longjmp.

If ofc was created with boost_context_swap, 'parm' will be an extra
parameter to the function.

Note that this can be potentially implemented with little or no overhead.

4. Add a variant of boost_context_swap that allows executing a
function on the destination context (in this case 'parm' would be
passed parameter to this function. This is mostly useful for injecting
an exception on the destination context. This can be potentially
implemented on top of the existing functionality, but would slow down
every context switch; a possible efficient implementation would
manipulate the destination stack to add a call to the function on top
of it, so that the cost is paid only when required.

5. Add a current context function (thread local).

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

[boost] [review] Boost.Context mini-review startstoday, January 2nd

Giovanni Piero Deretta — 2012-01-02T02:45:16

Hi all,

we will start a new year of Boost reviews with a one week mini-review
of the Boost.Context library of Oliver Kowalke. The review period
starts today January 2nd and ends January 11.

Please use [context review] as prefix of your post. Reviewers are
strongly encouraged to send their reviews to the boost development
mailing list as this is the I follow more assiduously.

Please note that Boost.Context was already reviewed and conditionally
accepted last May, so we are not voting for acceptance. Instead, this
mini-review is to discuss whether the library meets the conditions on
acceptance that were listed by Vicente Botet, the review manager at
that time. You'll find the whole list at the end of this email.

Since the end of the original review, Oliver has spent a large amount
of time on a partial rewrite of the library and both me and Oliver
decided to schedule this review only after we determined that all
issues had been addressed or at least considered.

In your review please state whether the acceptance conditions have
been addressed satisfactorily.

----------------------------------------------------------------------------------

About the library:

Boost.Context is a foundational library that provides a sort of
cooperative multitasking on a single thread. By providing an
abstraction of the current execution state in the current thread,
including the stack (with local variables) and stack pointer, all
registers and CPU flags, and the instruction pointer, a context
instance represents a specific point in the application's execution
path. This is useful for building higher-level abstractions, like
coroutines and fibers.

----------------------------------------------------------------------------------

Useful Links:

documentation: http://ok73.ok.funpic.de/boost/libs/context/doc/html/

library: git://github.com/olk/boost.context.git

----------------------------------------------------------------------------------


Point to be addressed before the mini review:

Design
1. Separation of the context class in two interface:
- A C-like interface that defines a POD struct that is memcpy-able and
that can be implemented either using platform libraries, as ucontext,
fibers or directly using assembler when a robust implementation is
available. The context swap implementation don't need to save the
signals as ucontext does. The following is just for illustrations
purposes.

struct boost_context;
typedef void boost_context_fn_t(intptr_t);

extern "C" void boost_context_make(boost_context* ctx,
boost_context_fn_t * f, intptr_t p, ...);
extern "C" void boost_context_swap(boost_context* from, boost_context
const* to);
extern "C" intptr_t boost_context_destroy( boost_context* fc);

boost_context_make is a merge of get_context with make_context + some
fields assignations.

"A user will have lower expectations from such a low level API and at
the same time will give more freedom for other people to implement on
top of it higher abstractions as Boost.Corutines, Boost.Fibers ..."

- A non-copiable but movable safe context class on top of the low
level C-like interface, that will provide modern and efficient C++
interface, that is usable by a user in a safe way.

The safe context class would just be one of the client of the C-like
interface, other library authors could either use the underlying
C-like API directly or the class context depending on wether they need
the speed or safety.

* The context class will not be templated any more, and the use of
type erasure will ensure that.
* The constructor will accept any C++ callable, function pointers, functors, ...
* At this high level interface, the function provided by the user
could throw exceptions, and the library must wrap the user function
and needs to store the exception raised and provide an interface to
retrieve them.

2. The stack implementation must ensure that the stack is unwound
before it is destroyed. A stack should only be safely deallocated if
either has been completely unwound or if it doesn't own any resources.

A basic stack without protection seems mandatory.

For debug purposes it has been required to provide some stack usage
functions that allow to know the max size used for example.

Implementation
3. The assembler implementation on Windows must be disallowed if the
ABI bug reported by Holger is confirmed. As far as Windows provides a
fiber implementation that is as efficient as the assembler one, the
assembler implementation is not mandatory and the user of the provided
Windows fiber is a preferable choice.

4. Most of the 'throw' statements in the context class should actually
be asserts.

5. The provided stack should be used to store any context parameters
as far as no major impediment is found during the implementation. This
will avoid further allocations on the safe context class.

Documentation
6. The documentation is very minimalist and should be expanded with a
discussion on context switching and use cases. Take care of all the
grammar/spelling improvements suggested by the reviewers (It will be
great if Jeffrey could review the documentation before the
mini-review). Some user land examples should be provided (why not the
yield example).

7. The concept of (Movable) Stack must be clearly defined, as it is
done in the standard, using expression requirements with semantic
constraints.

8. The assembler implementation should be carefully documented, so
others could maintain the code and add other implementations if
needed.

9. Some performance measure should be added. Providing the number of
cycles on each implemented platform would be nice.

Build system

10. The default build on a platform must work (It must be ABI
compatible with the underlying platform) and take care of the specific
features. Of course, the build needs to support cross compiling, so
the user should be able to override the default values.

Others points that are not required but that can make the library more
usable or efficient:

1. The assembler implementations could be simplified if the context
itself was represented as a single pointer to the top of the stack.
This would save some instructions to move the source address from the
stack return address to the context struct and back.

2. Instead of supporting a 'fc_link' a-la ucontext, have the callback
function return a new context (it is void now). 'fc_link' is useful
only on some limited cases (usually when you have an external
scheduler managing your contexts), while the having the callback
return the 'next continuation' has more applications (note that
fc_link can be implemented easily in term of the continuation
returning variant, but the reverse is harder). This will be very
useful, for example, to implement some kind of 'exit_to' functionality
(unwind the stack and restore another context), a key piece for safe
context destruction.

3. Give to boost_context_swap the ability to exchange a parameter with the
other context:

boost_context_parm_t boost_context_swap( boost_context * ofc,
boost_context const*
nfc, boost_context_parm_t parm)

where boost_context_parm_t is either

union boost_context_parm_t {
void * ptr;
int int_;
};

or simply intptr_t;

boost_context_swap saves the current context in ocf and restores the
context ncf as usual; additionally, if ofc was 'captured' on a call to
boost_context_swap, this call will return the value of parm on the
original context. This extra parameter is equivalent to the second
parameter of longjmp.

If ofc was created with boost_context_swap, 'parm' will be an extra
parameter to the function.

Note that this can be potentially implemented with little or no overhead.

4. Add a variant of boost_context_swap that allows executing a
function on the destination context (in this case 'parm' would be
passed parameter to this function. This is mostly useful for injecting
an exception on the destination context. This can be potentially
implemented on top of the existing functionality, but would slow down
every context switch; a possible efficient implementation would
manipulate the destination stack to add a call to the function on top
of it, so that the cost is paid only when required.

5. Add a current context function (thread local).

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

[C++ Now! 2012] Reminder: Call for Submissions,deadline is January 10th, 2012

Hartmut Kaiser — 2012-01-03T18:41:49

INAUGURAL C++ NOW! CONFERENCE 2012
Aspen CO, USA, May 14-18, 2012, www.cppnow.org

CALL FOR SUBMISSIONS

We invite you to submit session proposals to the Inaugural C++ Now!
Conference: C++Now! 2012 (Aspen CO, USA, May 14 - 18, 2012).

Based on the successful traditions of 5 years of BoostCon, which was
the main face-to-face event for all things C++ and Boost
(www.boost.org), C++Now! 2012 will present leading speakers from
the whole C++ community. The conference name is changing to C++
Now! to reflect the current value of the language, the focus on its
new state (from the new Standard), and the need to continually look 
to the future so the language remains useful to the C++ community.

The focus of this conference will be the new C++11 language Standard
and as usual Boost: what's new in C++, its Standard library, and in
the Boost libraries, how to write and maintain them, how to 
evangelize or to deploy Boost within your organization. The new C++ 
Standard, but also the infrastructure and process of Boost, its 
vision and mission - no matter what you are interested in, it all 
comes together in the C++Now! sessions. Meet the colleagues, and 
feel the inspiration to support your work with C++ and Boost for the 
next year.

The C++ Now! Conference is dedicated to discussion and education
about C++, an open and free language and standard.  Our Conference
will focus on discussion and education about open source software
usage and developments in the C++ developer and user community.

To reflect the breadth of the C++ and Boost communities, the
conference includes sessions aimed at three constituencies: C++ and
Boost end-users, hard-core Boost library and tool developers, and
researchers pushing the boundaries of computation. The program
fosters interaction and engagement within and across those groups,
with an emphasis on hands-on, participatory sessions.

As a multi-paradigm language, C++ is a melting pot where the most
compelling ideas from other programming communities are blended
in powerful ways.  Historically, some of the most popular sessions at
C++Now! have highlighted these concepts, from DSLs to functional
programming to transactional memory and more.  Bring your C#,
Python, Ruby or Haskell influences to bear in an environment that will
broaden their exposure.

IMPORTANT DATES
New proposal submissions due: January 10th, 2012.
Proposals decisions sent (tentative program): February 17th, 2012.
Fully scheduled program available: February 25th, 2012.
Session materials due: April 15th, 2012.

BEST PRESENTATION AWARDS

We know how much effort it takes to prepare talks for our conference.
For this reason we will award the best presentations in the following
categories: Best Presentation, Best Short Presentation, Best Tutorial,
and Best Workshop. The awards will be given based on the audience's
voting. Each award will include the author's name listed on the cover
of the C++Now! website for that year and a plaque containing all the
C++Now! conference information.

SESSION TOPICS

Topics of interest include, but are not restricted to, the following:
*    C++11 and how it changes life for users and library writers
*    General tutorial sessions on C++11, the C++11 Standardslibrary,
     and one or more Boost libraries
*    In-depth sessions on using specific Boost libraries
*    Case studies on using Boost
*    Experts panels
*    Advanced sessions on implementation techniques used within Boost
     libraries
*    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
*    Software development tools and their application to C++ and or
     Boost
*    Other topics likely to be of great interest to Boost users and
     developers

Interactive and collaborative sessions are encouraged, as this is 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 C++11, Boost
and
                  users.
Panels            Panels feature three or four people presenting their
                  ideas and experiences relating to C++11 and 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 skills relevant to
                  C++11 and Boost.
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   These were introduced at BoostCon 2008, and were a
                  great Presentations 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 in Boost libraries.
Tool Vendors      We actively encourage tool vendors and ISP's to
                  submit presentations 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 60 minutes. You may submit a proposal for
fractions or multiples of 90-minutes. Fractional proposals will be
grouped into 60 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 short-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 should be made through the EasyChair conference
management system: http://www.easychair.org/conferences/?conf=cppnow2012.
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 (but are not required) 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 proposals 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 C++Now! website and will be available
to attendees.

For general information on the C++Now! 2012 paper submission or
the scope of technical papers solicited, please refer to the
conference
website at www.cppnow.org. For any other questions about the
submission process or paper format, please contact the Program
Committee at cppnow2012< at >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 C++ Now!.

Hartmut Kaiser, email: hartmut.kaiser< at >gmail.com (Program Committee
Chair)
Dave Abrahams, email: dave< at >boostpro.com (Conference Chair)

On behalf of the conference organizers

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

[boost] [review] Boost.Context mini-review startstoday, January 2nd

Giovanni Piero Deretta — 2012-01-02T02:45:16

Hi all,

we will start a new year of Boost reviews with a one week mini-review
of the Boost.Context library of Oliver Kowalke. The review period
starts today January 2nd and ends January 11.

Please use [context review] as prefix of your post. Reviewers are
strongly encouraged to send their reviews to the boost development
mailing list as this is the I follow more assiduously.

Please note that Boost.Context was already reviewed and conditionally
accepted last May, so we are not voting for acceptance. Instead, this
mini-review is to discuss whether the library meets the conditions on
acceptance that were listed by Vicente Botet, the review manager at
that time. You'll find the whole list at the end of this email.

Since the end of the original review, Oliver has spent a large amount
of time on a partial rewrite of the library and both me and Oliver
decided to schedule this review only after we determined that all
issues had been addressed or at least considered.

In your review please state whether the acceptance conditions have
been addressed satisfactorily.

----------------------------------------------------------------------------------

About the library:

Boost.Context is a foundational library that provides a sort of
cooperative multitasking on a single thread. By providing an
abstraction of the current execution state in the current thread,
including the stack (with local variables) and stack pointer, all
registers and CPU flags, and the instruction pointer, a context
instance represents a specific point in the application's execution
path. This is useful for building higher-level abstractions, like
coroutines and fibers.

----------------------------------------------------------------------------------

Useful Links:

documentation: http://ok73.ok.funpic.de/boost/libs/context/doc/html/

library: git://github.com/olk/boost.context.git

----------------------------------------------------------------------------------


Point to be addressed before the mini review:

Design
1. Separation of the context class in two interface:
- A C-like interface that defines a POD struct that is memcpy-able and
that can be implemented either using platform libraries, as ucontext,
fibers or directly using assembler when a robust implementation is
available. The context swap implementation don't need to save the
signals as ucontext does. The following is just for illustrations
purposes.

struct boost_context;
typedef void boost_context_fn_t(intptr_t);

extern "C" void boost_context_make(boost_context* ctx,
boost_context_fn_t * f, intptr_t p, ...);
extern "C" void boost_context_swap(boost_context* from, boost_context
const* to);
extern "C" intptr_t boost_context_destroy( boost_context* fc);

boost_context_make is a merge of get_context with make_context + some
fields assignations.

"A user will have lower expectations from such a low level API and at
the same time will give more freedom for other people to implement on
top of it higher abstractions as Boost.Corutines, Boost.Fibers ..."

- A non-copiable but movable safe context class on top of the low
level C-like interface, that will provide modern and efficient C++
interface, that is usable by a user in a safe way.

The safe context class would just be one of the client of the C-like
interface, other library authors could either use the underlying
C-like API directly or the class context depending on wether they need
the speed or safety.

* The context class will not be templated any more, and the use of
type erasure will ensure that.
* The constructor will accept any C++ callable, function pointers, functors, ...
* At this high level interface, the function provided by the user
could throw exceptions, and the library must wrap the user function
and needs to store the exception raised and provide an interface to
retrieve them.

2. The stack implementation must ensure that the stack is unwound
before it is destroyed. A stack should only be safely deallocated if
either has been completely unwound or if it doesn't own any resources.

A basic stack without protection seems mandatory.

For debug purposes it has been required to provide some stack usage
functions that allow to know the max size used for example.

Implementation
3. The assembler implementation on Windows must be disallowed if the
ABI bug reported by Holger is confirmed. As far as Windows provides a
fiber implementation that is as efficient as the assembler one, the
assembler implementation is not mandatory and the user of the provided
Windows fiber is a preferable choice.

4. Most of the 'throw' statements in the context class should actually
be asserts.

5. The provided stack should be used to store any context parameters
as far as no major impediment is found during the implementation. This
will avoid further allocations on the safe context class.

Documentation
6. The documentation is very minimalist and should be expanded with a
discussion on context switching and use cases. Take care of all the
grammar/spelling improvements suggested by the reviewers (It will be
great if Jeffrey could review the documentation before the
mini-review). Some user land examples should be provided (why not the
yield example).

7. The concept of (Movable) Stack must be clearly defined, as it is
done in the standard, using expression requirements with semantic
constraints.

8. The assembler implementation should be carefully documented, so
others could maintain the code and add other implementations if
needed.

9. Some performance measure should be added. Providing the number of
cycles on each implemented platform would be nice.

Build system

10. The default build on a platform must work (It must be ABI
compatible with the underlying platform) and take care of the specific
features. Of course, the build needs to support cross compiling, so
the user should be able to override the default values.

Others points that are not required but that can make the library more
usable or efficient:

1. The assembler implementations could be simplified if the context
itself was represented as a single pointer to the top of the stack.
This would save some instructions to move the source address from the
stack return address to the context struct and back.

2. Instead of supporting a 'fc_link' a-la ucontext, have the callback
function return a new context (it is void now). 'fc_link' is useful
only on some limited cases (usually when you have an external
scheduler managing your contexts), while the having the callback
return the 'next continuation' has more applications (note that
fc_link can be implemented easily in term of the continuation
returning variant, but the reverse is harder). This will be very
useful, for example, to implement some kind of 'exit_to' functionality
(unwind the stack and restore another context), a key piece for safe
context destruction.

3. Give to boost_context_swap the ability to exchange a parameter with the
other context:

boost_context_parm_t boost_context_swap( boost_context * ofc,
boost_context const*
nfc, boost_context_parm_t parm)

where boost_context_parm_t is either

union boost_context_parm_t {
void * ptr;
int int_;
};

or simply intptr_t;

boost_context_swap saves the current context in ocf and restores the
context ncf as usual; additionally, if ofc was 'captured' on a call to
boost_context_swap, this call will return the value of parm on the
original context. This extra parameter is equivalent to the second
parameter of longjmp.

If ofc was created with boost_context_swap, 'parm' will be an extra
parameter to the function.

Note that this can be potentially implemented with little or no overhead.

4. Add a variant of boost_context_swap that allows executing a
function on the destination context (in this case 'parm' would be
passed parameter to this function. This is mostly useful for injecting
an exception on the destination context. This can be potentially
implemented on top of the existing functionality, but would slow down
every context switch; a possible efficient implementation would
manipulate the destination stack to add a call to the function on top
of it, so that the cost is paid only when required.

5. Add a current context function (thread local).

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

[C++ Now! 2012] Reminder: Call for Submissions,deadline is January 10th, 2012

Hartmut Kaiser — 2012-01-03T18:41:49

INAUGURAL C++ NOW! CONFERENCE 2012
Aspen CO, USA, May 14-18, 2012, www.cppnow.org

CALL FOR SUBMISSIONS

We invite you to submit session proposals to the Inaugural C++ Now!
Conference: C++Now! 2012 (Aspen CO, USA, May 14 - 18, 2012).

Based on the successful traditions of 5 years of BoostCon, which was
the main face-to-face event for all things C++ and Boost
(www.boost.org), C++Now! 2012 will present leading speakers from
the whole C++ community. The conference name is changing to C++
Now! to reflect the current value of the language, the focus on its
new state (from the new Standard), and the need to continually look 
to the future so the language remains useful to the C++ community.

The focus of this conference will be the new C++11 language Standard
and as usual Boost: what's new in C++, its Standard library, and in
the Boost libraries, how to write and maintain them, how to 
evangelize or to deploy Boost within your organization. The new C++ 
Standard, but also the infrastructure and process of Boost, its 
vision and mission - no matter what you are interested in, it all 
comes together in the C++Now! sessions. Meet the colleagues, and 
feel the inspiration to support your work with C++ and Boost for the 
next year.

The C++ Now! Conference is dedicated to discussion and education
about C++, an open and free language and standard.  Our Conference
will focus on discussion and education about open source software
usage and developments in the C++ developer and user community.

To reflect the breadth of the C++ and Boost communities, the
conference includes sessions aimed at three constituencies: C++ and
Boost end-users, hard-core Boost library and tool developers, and
researchers pushing the boundaries of computation. The program
fosters interaction and engagement within and across those groups,
with an emphasis on hands-on, participatory sessions.

As a multi-paradigm language, C++ is a melting pot where the most
compelling ideas from other programming communities are blended
in powerful ways.  Historically, some of the most popular sessions at
C++Now! have highlighted these concepts, from DSLs to functional
programming to transactional memory and more.  Bring your C#,
Python, Ruby or Haskell influences to bear in an environment that will
broaden their exposure.

IMPORTANT DATES
New proposal submissions due: January 10th, 2012.
Proposals decisions sent (tentative program): February 17th, 2012.
Fully scheduled program available: February 25th, 2012.
Session materials due: April 15th, 2012.

BEST PRESENTATION AWARDS

We know how much effort it takes to prepare talks for our conference.
For this reason we will award the best presentations in the following
categories: Best Presentation, Best Short Presentation, Best Tutorial,
and Best Workshop. The awards will be given based on the audience's
voting. Each award will include the author's name listed on the cover
of the C++Now! website for that year and a plaque containing all the
C++Now! conference information.

SESSION TOPICS

Topics of interest include, but are not restricted to, the following:
*    C++11 and how it changes life for users and library writers
*    General tutorial sessions on C++11, the C++11 Standardslibrary,
     and one or more Boost libraries
*    In-depth sessions on using specific Boost libraries
*    Case studies on using Boost
*    Experts panels
*    Advanced sessions on implementation techniques used within Boost
     libraries
*    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
*    Software development tools and their application to C++ and or
     Boost
*    Other topics likely to be of great interest to Boost users and
     developers

Interactive and collaborative sessions are encouraged, as this is 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 C++11, Boost
and
                  users.
Panels            Panels feature three or four people presenting their
                  ideas and experiences relating to C++11 and 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 skills relevant to
                  C++11 and Boost.
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   These were introduced at BoostCon 2008, and were a
                  great Presentations 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 in Boost libraries.
Tool Vendors      We actively encourage tool vendors and ISP's to
                  submit presentations 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 60 minutes. You may submit a proposal for
fractions or multiples of 90-minutes. Fractional proposals will be
grouped into 60 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 short-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 should be made through the EasyChair conference
management system: http://www.easychair.org/conferences/?conf=cppnow2012.
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 (but are not required) 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 proposals 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 C++Now! website and will be available
to attendees.

For general information on the C++Now! 2012 paper submission or
the scope of technical papers solicited, please refer to the
conference
website at www.cppnow.org. For any other questions about the
submission process or paper format, please contact the Program
Committee at cppnow2012< at >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 C++ Now!.

Hartmut Kaiser, email: hartmut.kaiser< at >gmail.com (Program Committee
Chair)
Dave Abrahams, email: dave< at >boostpro.com (Conference Chair)

On behalf of the conference organizers

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

[Review Results:Algorithms] Boost.Algorithms isaccepted

Dave Abrahams — 2011-12-20T20:20:20

Having “reviewed the reviews” of Boost.Algorithms, I'm pleased to announce
that it is unconditionally accepted.  Congratulations to Marshall Clow!

There were 5 yes votes and 1 no vote.

The issues raised in all reviews were taken seriously by Marshall and
recorded in the issue tracker at
https://github.com/mclow/Boost.Algorithm

I trust that Marshall will address the most important ones immediately,
so I feel no need to place conditions on acceptance.  Among the most
important issues:

https://github.com/mclow/Boost.Algorithm/issues/19
https://github.com/mclow/Boost.Algorithm/issues/18
https://github.com/mclow/Boost.Algorithm/issues/16
https://github.com/mclow/Boost.Algorithm/issues/15
https://github.com/mclow/Boost.Algorithm/issues/2

Thanks, everybody, for your participation!

[boost] [review] [Local] Review Result - ACCEPTED

Jeffrey Lee Hellrung, Jr. — 2011-12-12T08:15:19

Local is ACCEPTED into Boost.

After following the lively Local review discussion several weeks ago, and
reviewing the discussion a second (and sometimes third) time, I have come
to the above conclusion. There was quite a bit of passion on both the sides
of "aisle", and thus, obviously, no decision I make would be well-received
by all.

Let me start by summarizing the main arguments against including Local in
Boost:

(a) Local functions are not very useful, at least in the presence of
existing alternatives (e.g., namespace functions and Boost.Phoenix).
(b) Local is really a portability library for C++03 presenting an imperfect
emulation of features readily available in C++11.
(c) Local's interface is primarily macro-based, making code ugly and
difficult to read.

In my opinion as the review manager, a sufficient number of individuals in
the discussion found the library "useful" to address (a) (sometimes with
additional positive adverbs); indeed, at least a couple individuals have
shared positive experiences with real-world use. Namespace functions
require one to move code to somewhere other than where one may prefer to
have it, and often requires a significant amount of boilerplate when
binding local variables. Aside from any perceived issues with
Boost.Phoenix's syntax and compiler error messages, it has been noted that
binding member functions within Boost.Phoenix can get ugly. As far as (b)
is concerned, the community seems pretty far from reaching a consensus on
whether a library described by (b) belongs in Boost. There are certainly
libraries currently in Boost that could be pegged to satisfy (b) as well,
though they all have other mitigating features they make their situation
different from Local in some way. As far as (c) is concerned, several have
acknowledged that a macro-based interface is necessary to implement local
functions in C++03, and it seems to have been generally agreed that, given
this limitation, Lorenzo has done an admireable job making the interface as
easy-to-use as possible. Some find it ugly, others find it reasonable.

In addition to the counterarguments of (a-c) above, the following facts
weighed into my final decision:
* Lorenzo has been engaging and in constant communication with the
developer's list during the development of Local. This gives me confidence
that he will continue to actively maintain (and improve?) Local.
* The documentation is unanimously agreed to be of Boost quality.
* The transition of some organizations from C++03 to C++11 may take several
more years, and Boost has a history of supporting "ancient" compilers (for
better or worse). The point being, a library that eases the transition from
C++03 to C++11 has some merit based on current precedent.
* There had been previous work on local functions by Alexander Nasanov and
Steven Watanabe shared on the developer's list, suggesting a desire for
this functionality for some time.
* Local is approximately an extension of Boost.ScopeExit; indeed, it
basically fulfills the request to Alexander Nasanov from the review result
[2] of Boost.ScopeExit to create such an extension.

Lastly, my own opinion of "what Boost is" factored in here. I view Boost as
*partly* a collection of general purpose libraries that can be used in wide
variety of applications (and thus Boost frequently acts as a staging ground
for standard adoption). Based on review feedback, I believe Local satisfies
this criterion; and based on the mailing list discussion, I believe this
view of Boost is not entirely inconsistent with others on the mailing list.

Ultimately, it wasn't so much a # of "yes" votes versus # of "no" votes as
it was the above general considerations. Regardless, I think independent of
how the votes were counted, the "yes" votes outnumbered the "no" votes.
This required some discretion on my part as not everyone who expressed an
opinion submitted a formal review, and some participants were only arguing
in favor of some specific point supporting either acceptance or rejection
of Local.

"Yes" reviews (7)
--------
Krzysztof Czainski
Andrzej Krzemienski
Pierre Morcello
Nat Lindon
John Bytheway
Edward Diener
Gregory Crosswhite

"No" reviews (3)
--------
Vicente J. Botet
Thomas Heller
Hartmut Kaiser

Paul A. Bristow and Alexander Nasanov (the author of Boost.ScopeExit) both
submitted reviews but did not express an opinion (as far as I could tell)
on whether Local should be included in Boost, though if I had to peg
Paul's, it would be to reject Local. From what I gathered, Joel de Guzman,
Joel Falcou, Dean Michael Berris, and Lucanus J. Simonson were opposed to
including Local in Boost (the aforementioned did not submit a formal
review, though a formal review might be unnecessary if your vote is "no").
On the other hand, Brian Wood, Philippe Vaucher, Mathias Gaunard, Robert
Ramey, Nathan Ridge, Brent Spillner, Thomas Klimpel, Christopher Jefferson,
Daniel James, Rafael Fourquet, Matthias Schabel, and Robert Stewart
participated in the discussion and argued in favor of some point that
supported accepting Local in Boost. I want to be clear here that certainly
not everyone in the aforementioned list even implied that they supported
acceptance of Local (I would guess that only roughly half implied as much),
but they indirectly helped its case by addressing arguments against
inclusion. Overall, that indicates to me that more individuals support
acceptance of Local into Boost than rejection.

[Apologies for any name misspellings and absent accents.]

Regarding Boost.ScopeExit: 4 reviews were in favor of deprecating
Boost.ScopeExit; 3 reviews felt there was nothing wrong with both
Boost.ScopeExit and Local coexisting; and 3 reviews mentioned the
possibility of improving Boost.ScopeExit with the features provided by
Local's exits. As such I'm inclined to let Alexander (who opposed any kind
of merging of Local and Boost.ScopeExit) work with Lorenzo on improving
Boost.ScopeExit as he sees fit, and hopefully both libraries can address
this apparent duplication of functionality within their respective
documentation to avoid user confusion.

Regarding local::function::overload: Based on the review comments, it makes
the most sense to add this to Boost.Functional.

Regarding BOOST_IDENTITY_TYPE: This should be added to Boost.Utility. On
the other hand, there doesn't appear to be a compelling use case for
BOOST_IDENTITY_VALUE.

The following are some suggested *possible* improvements that reviewers
brought up. This list is by no means exhaustive. Further, I personally
don't think all of these suggestions are necessarily "good", but I think
it's fair for Lorenzo (and the community) to consider them nonetheless.
Parenthetic comments are my own opinions.

* Some aren't convinced of the utility of LOCAL_BLOCK. (It's use cases
appear fairly narrow so it might be best to simplify the library and remove
this capability.)
* Use "this_" (as opposed to "_this") as an alias for "this" within
function bodies, and possibly also within bind declarations.
* Present Boost.PP sequence interface as a workaround for the variadic
interface? (I don't have a problem with supporting both interfaces at the
top level.)
* "Local" and "Locale" look too much alike, suggesting a name change to
"Scope", "Scoped", "LocalFunction", "Closure" may be a good idea?
* Allow use without dependence on Boost.TypeOf.
* Rename prefix and postfix macros from XXX_PARAMS/XXX_NAME to XXX/XXX_END?
(I don't mind the current macros.)
* Explicitly separate bound variables from function parameters. (I think
this suggestion has merit but I don't know what the interface could look
like.)
* Remove support for default parameters to simplify interface and
documentation? (It doesn't seem like default function parameters would be
very useful.)
* Use "capture" instead of "bind" for the bind/capture keyword? (I like and
prefer "bind".)

Finally, here the links to the submitted formal reviews, for reference. Of
particular note are Krzysztof's and John's reviews for their comments on
the documentation. Some "yes" votes were conditional, but AFAIK Lorenzo has
already agreed to address the relevant conditions.

Krzysztof Czainski
http://permalink.gmane.org/gmane.comp.lib.boost.devel/225543

Vicente J. Botet
http://permalink.gmane.org/gmane.comp.lib.boost.devel/225604

Andrzej Krzemienski
http://permalink.gmane.org/gmane.comp.lib.boost.devel/225656

Paul A. Bristow
[...cannot find link to review...]

Pierre Morcello
http://permalink.gmane.org/gmane.comp.lib.boost.devel/225694

Nat Lindon
http://permalink.gmane.org/gmane.comp.lib.boost.user/71508

Thomas Heller
http://permalink.gmane.org/gmane.comp.lib.boost.devel/225736

Hartmut Kaiser
http://permalink.gmane.org/gmane.comp.lib.boost.devel/225745

John Bytheway
http://permalink.gmane.org/gmane.comp.lib.boost.devel/225746

Alexander Nasanov
http://permalink.gmane.org/gmane.comp.lib.boost.devel/225783

Edward Diener
http://permalink.gmane.org/gmane.comp.lib.boost.devel/225795

Gregory Crosswhite
http://permalink.gmane.org/gmane.comp.lib.boost.devel/225807

Finally, really big thanks to everyone for participating in the review and
ancillary discussions. I attempted to be as transparent as possible in
outlining the rationale for my decision above, but if you have any further
questions, do not hesitate to ask.

- Jeff, Review Manager for Local

[1] http://thread.gmane.org/gmane.comp.lib.boost.devel/168612
[2] http://lists.boost.org/boost-announce/2008/05/0190.php
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

Boost 1.48.0 Release Notice

Beman Dawes — 2011-11-16T13:35:19

Release 1.48.0 of the Boost C++ Libraries is now available.

These open-source libraries work well with the C++ Standard Library,
and are usable across a broad spectrum of applications. The Boost
license encourages both commercial and non-commercial use.

This release contains new libraries: Container, Locale, Move. Updated
libraries include: Asio, Chrono, Config, Fusion, Geometry, Graph,
Interprocess, Intrusive, Lexical cast, Math, MSM, Numeric Conversion,
Proto, Regex, Spirit, TypeTraits, Unordered, Wave, and more.  For
details, including download links, see
http://www.boost.org/users/news/version_1_48_0

You can also download directly from SourceForge:
http://sourceforge.net/projects/boost/files/boost/1.48.0/

To install this release on your system, see
http://www.boost.org/doc/libs/release/more/getting_started/index.html

Thanks,

--The Boost release team

     Beman Dawes
     Daniel James
     Eric Niebler
     Rene Rivera
     Vladimir Prus
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

[boost] Boost.Local Review (Nov 10, 2011 to Nov 19,2011)

Jeffrey Lee Hellrung, Jr. — 2011-11-10T05:52:53

Hi all,

It is time!

The review of Lorenzo Caminiti's proposed Boost.Local library begins
tomorrow, ***November 10, 2011***, and ends on ***November 19, 2011***.

Boost.Local implements local functions, local blocks, and local exits for
the C++ programming language. It allows one to define a function at any
declarative scope, including function scope; bind variables from the
enclosing scope; and pass this function to templated STL-style algorithms.

Please see the Introduction of the documentation for a longer but still
brief overview.

--------

The code and documentation are available from the Boost sandbox (
https://svn.boost.org/svn/boost/sandbox/):

https://svn.boost.org/svn/boost/sandbox/local/ [everything]
https://svn.boost.org/svn/boost/sandbox/local/boost/ [code]
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.html[documentation]

--------

Please state clearly whether you think this library should be accepted as a
Boost library.

Other questions you may want to consider:

- 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?

Please also consider the following issues and proposals specific to
Boost.Local. Your opinion is welcome on any or all of these.

- Boost.Local's local exits provide the same functionality (and then some)
as Boost.ScopeExit. Does this duplication of functionality need to be
dealt with, and if so, how?
- Lorenzo is proposing to add boost::local::function::
overload to Boost.Function as boost::function::overload. See
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/local/function/overload.html
- Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. See
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDENTITY_TYPE.html
- Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to
boost/utility. See
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDENTITY_VALUE.html

--------

Lastly, please note that Boost.Local has included a copy of the Variadic
Macro Data (VMD) library in boost/detail/preprocessor/variadic_macro_data.
Since then, VMD has been modified and integrated into Boost.Preprocessor.
After the review has concluded, Lorenzo will remove this local copy of the
VMD library and replace its usage within Boost.Local with the
Boost.Preprocessor variadic extensions.

--------

Thanks in advance to all who participate in the review discussion; I'm
looking forward to it!

- Jeffrey Hellrung (Review Manager)
- Gregory Crosswhite (Review Assistant)
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

[boost] [atomic] review results

Tim Blechmann — 2011-11-07T15:41:44

hi all,

unfortunately only few reviews of boost.atomic arrived in time, however i 
count 3 YES and no NO, so i am happy to say:


   Helge Bahmann's boost.atomic library is ACCEPTED.


since the library is an implementation of a c++11 feature for c++03, design, 
API and semantics are mostly fixed. many comments are going into details of 
the implementation, so i won't sum them all up ... iac, helge already said he 
wants to address the raised issues, the main points are summarized below.


full implementation of the c++11 interface:
the library currently only implements a subset of the c++11 library. it lacks 
the functional interface for integral atomic types and the ATOMIC_VAR_INIT / 
ATOMIC_FLAG_INIT macro. quickly consulting the latest draft that i currently 
have at hand the following two functions are missing as well:

template <class T> T kill_dependency(T y);
void atomic_signal_fence(memory_order);

i encourage helge to provide a full implementation of the interface.


documentation:
the documentation is currently lacking a good API reference. i would therefore 
encourage helge to provide a doxygen-generated reference section. there were 
some concerns that it assumes that readers will have to be familiar with 
concurrency. maybe it is a good idea to point to some literature/tutorials 
about concurrent programming and/or to c++11 atomics.
the section of real-world examples could probably include a link to 
shavit/herlihy's book `the art of multiprocessor programming'.
it would also be helpful to have a detailed specification, if a 
platform/compiler combination supports a specific type natively (with run-time 
dispatching or specific compiler flags) ... maybe in form of a table.


shared memory support/multi-module support:
in multi-module applications and when using shared memory, the blocking 
emulation of atomics can cause troubles. for multi-module applications this 
can be resolved by placing the spinlock pool inside a shared library. shared-
memory support could be realized by associating a (spin)lock with each 
blocking atomic<> instead of using a pool of spinlocks. boost should 
definitely provide atomics which support shared memory, either by default or 
by an additional implementation which is placed in the boost::interprocess 
namespace.


i would like to thank helge for implementing boost.atomic and submitting it to 
boost and everyone who participated in the review.

cheers, tim
review manager


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

[boost] [Boost.Endian] Review Results

joel falcou — 2011-11-03T18:53:03

Hi everyone,

after some delay, here is the result of the review of Beman Dawes' Boost.Endian library. First, I want to thanks all participants
of the review that lead to very deep and interesting discussions on the matter.

5 votes were cast : 2 unconditionally in favor, 3 conditionally in favor after changes made and there is a mini-review.
The verdict is that Boost.Endian is **CONDITIONNALY ACCEPTED**

Here is what needs to be done to get the library ready for a mini-review:

* Common use case scenarios should be developed.
* Example programs should be developed for the common use case scenarios.
* Documentation should illuminate the differences between endian integer/float type and endian conversion approaches to the common use case scenarios, and provide guidelines for choosing the most appropriate approach in user's applications.
* Conversion functions supplying results via return should be provided.
* Platform specific performance enhancements such as use of compiler intrinsics or relaxed alignment requirements should be supported.
* Endian integer (and floating) types should be implemented via the conversion functions. If that can't be done efficiently, consideration should be given to expanding the conversion function signatures to resolve the inefficiencies.
* Benchmarks that measure performance should be provided. It should be possible to compare platform specific performance enhancements against portable base implementations, and to compare endian integer approaches against endian conversion approaches for the common use case scenarios.
* Float (32-bits) and double (64-bits) should be supported. IEEE 754 is the primary use case.
* Support for user defined types (UDTs) is desirable, and should be provided where there would be no conflict with the other concerns.
* There is some concern that endian integer/float arithmetic operations might used inadvertently or inappropriately. The impact of adding an endian_buffer class without arithmetic operations should be investigated.
* Stream insertion and extraction of the endian integer/float types should be documented and included in the test coverage.
* Binary I/O support that was investigated during development of the Endian library should be put up for mini-review for inclusion in the Boost I/O library.


Regards


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

[C++ Now! 2012] Call for Submissions

Hartmut Kaiser — 2011-10-30T14:28:14

INAUGURAL C++ NOW! CONFERENCE 2012
Aspen CO, USA, May 14-18, 2012, www.cppnow.org

CALL FOR SUBMISSIONS

We invite you to submit session proposals to the Inaugural C++ Now!
Conference: C++Now! 2012 (Aspen CO, USA, May 14 - 18, 2012).

Based on the successful traditions of 5 years of BoostCon, which was
the main face-to-face event for all things C++ and Boost
(www.boost.org), C++Now! 2012 will present leading speakers from
the whole C++ community. The conference name is changing to C++
Now! to reflect the current value of the language, the focus on its new
state (from the new Standard), and the need to continually look to the
future so the language remains useful to the C++ community.

The focus of this conference will be the new C++11 language Standard
and as usual Boost: what's new in C++, its Standard library, and in the
Boost libraries, how to write and maintain them, how to evangelize or
to deploy Boost within your organization. The new C++ Standard, but
also the infrastructure and process of Boost, its vision and mission -
no matter what you are interested in, it all comes together in the
C++Now! sessions. Meet the colleagues, and feel the inspiration to
support your work with C++ and Boost for the next year.

The C++ Now! Conference is dedicated to discussion and education
about C++, an open and free language and standard.  Our Conference
will focus on discussion and education about open source software
usage and developments in the C++ developer and user community.

To reflect the breadth of the C++ and Boost communities, the
conference includes sessions aimed at three constituencies: C++ and
Boost end-users, hard-core Boost library and tool developers, and
researchers pushing the boundaries of computation. The program
fosters interaction and engagement within and across those groups,
with an emphasis on hands-on, participatory sessions.

As a multi-paradigm language, C++ is a melting pot where the most
compelling ideas from other programming communities are blended
in powerful ways.  Historically, some of the most popular sessions at
C++Now! have highlighted these concepts, from DSLs to functional
programming to transactional memory and more.  Bring your C#,
Python, Ruby or Haskell influences to bear in an environment that will
broaden their exposure.

IMPORTANT DATES
New proposal submissions due: January 10th, 2012.
Proposals decisions sent (tentative program available): February 17th, 2012.
Fully scheduled program available: February 25th, 2012.
Session materials due: April 15th, 2012.

BEST PRESENTATION AWARDS

We know how much effort it takes to prepare talks for our conference.
For this reason we will award the best presentations in the following
categories: Best Presentation, Best Short Presentation, Best Tutorial,
and Best Workshop. The awards will be given based on the audience's
voting. Each award will include the author's name listed on the cover
of the C++Now! website for that year and a plaque containing all the
C++Now! conference information.

SESSION TOPICS

Topics of interest include, but are not restricted to, the following:
*    C++11 and how it changes life for users and library writers
*    General tutorial sessions on C++11, the C++11 Standardslibrary,
     and one or more Boost libraries
*    In-depth sessions on using specific Boost libraries
*    Case studies on using Boost
*    Experts panels
*    Advanced sessions on implementation techniques used within Boost
     libraries
*    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
*    Software development tools and their application to C++ and or
     Boost
*    Other topics likely to be of great interest to Boost users and
     developers

Interactive and collaborative sessions are encouraged, as this is 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 C++11, Boost and
                  users.
Panels            Panels feature three or four people presenting their
                  ideas and experiences relating to C++11 and 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 skills relevant to
                  C++11 and Boost.
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   These were introduced at BoostCon 2008, and were a great
Presentations     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 in Boost libraries.
Tool Vendors      We actively encourage tool vendors and ISP's to submit
Presentations     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 60 minutes. You may submit a proposal for
fractions or multiples of 90-minutes. Fractional proposals will be
grouped into 60 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 short-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 should be made through the EasyChair conference
management system: http://www.easychair.org/conferences/?conf=cppnow2012.
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 (but are not required) 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 proposals 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 C++Now! website and will be available
to attendees.

For general information on the C++Now! 2012 paper submission or
the scope of technical papers solicited, please refer to the conference
website at www.cppnow.org. For any other questions about the
submission process or paper format, please contact the Program
Committee at cppnow2012< at >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 C++ Now!.

Hartmut Kaiser, email: hartmut.kaiser< at >gmail.com (Program Committee Chair)
Dave Abrahams, email: dave< at >boostpro.com (Conference Chair)

On behalf of the conference organizers
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

[boost] [Review] Boost.Atomic review starts today,October 17th 2011

Tim Blechmann — 2011-10-16T23:45:12

Hi all,

The review of Helge Bahmann's Boost.Atomic library starts today, October 
17th 2011. It will end on October 26th.

I encourage everyone to participate the the discussion on the Boost mailing 
list about this very important library. In addition the code can be reviewed 
line-by-line in code collaborator (http://demo.smartbear.com/boost/)

About Boost.Atomic:
Boost.Atomic is a library that provides atomic data types and operations on 
these data types, as well as memory ordering constraints required for 
coordinating multiple threads through atomic variables. It implements the 
interface as defined by the C++11 standard, but makes this feature available 
for platforms lacking system/compiler support for this particular C++11 
feature.

Tarball:
http://www.chaoticmind.net/~hcb/projects/boost.atomic/boost.atomic.tar.gz

Documentation:
http://www.chaoticmind.net/~hcb/projects/boost.atomic/doc/index.html

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? On which platform? 
 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?

Cheers, Tim
Review Manager

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce