Marshall Clow | 18 Jul 17:01 2014
Picon

[1.56.0] Beta 1 Available

Boost release 1.56.0 beta 1 is now available from SourceForge

See http://sourceforge.net/projects/boost/files/boost/1.56.0.beta.1/

This release contains 2 new libraries:
* Align: Memory alignment functions, allocators, and adaptors, from Glen Fernandes.
* Type_Index: Runtime/Compile time copyable type info, from Antony Polukhin.

Modularization
Boost version control has migrated to a system using git submodules. This shouldn't make too much of a difference to users, although the directory structure is now a bit different.

Parts of some libraries have been moved into different modules, and several new modules have been extracted from existing code. All header paths should remain the same.

The new modules are:
* Assert: Customizable assert macros. Maintained by Peter Dimov.
* Core: Core utilities used by other libraries, with minimal dependencies. Maintained by Peter Dimov, Glen Fernandes and Andrey Semashev.
* Lexical_Cast: General literal text conversions, such as an int represented a string, or vice-versa, from Kevlin Henney.
* Throw_Exception: A common infrastructure for throwing exceptions from Boost libraries, from Emil Dotchevski.
* Winapi: Windows API declarations without <windows.h>, for internal Boost use.

For details of what's in the release, see http://www.boost.org/users/history/version_1_56_0.html
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,

-- The Boost Release Team
<div>
<span>Boost release 1.56.0 beta 1 is now available from SourceForge</span><br><br><span>See&nbsp;</span><a href="http://sourceforge.net/projects/boost/files/boost/1.56.0.beta.1/">http://sourceforge.net/projects/boost/files/boost/1.56.0.beta.1/</a><br><br>This release contains 2 new libraries:<br><span class="Apple-tab-span">	</span>* Align: Memory alignment functions, allocators, and adaptors, from Glen Fernandes.<br><span class="Apple-tab-span">	</span>* Type_Index: Runtime/Compile time copyable type info, from Antony Polukhin.<br><br>Modularization<br>Boost version control has migrated to a system using git submodules. This shouldn't make too much of a difference to users, although&nbsp;the directory structure is now a bit different.<br><br>Parts of some libraries have been moved into different modules, and several new modules have been extracted from existing code. All&nbsp;header paths should remain the same.<div><span><br></span></div>
<div>
<span>The new modules are:</span><div>
<div>
<span class="Apple-tab-span">	</span>* Assert:&nbsp;Customizable assert macros. Maintained by Peter Dimov.<br>
</div>
<div>
<span class="Apple-tab-span">	</span>* Core:&nbsp;Core utilities used by other libraries, with minimal dependencies. Maintained by Peter Dimov, Glen Fernandes and Andrey&nbsp;Semashev.<br>
</div>
<div>
<span class="Apple-tab-span">	</span>* Lexical_Cast:&nbsp;General literal text conversions, such as an int represented a string, or vice-versa, from Kevlin Henney.<br>
</div>
<div>
<span class="Apple-tab-span">	</span>* Throw_Exception:&nbsp;A common infrastructure for throwing exceptions from Boost libraries, from Emil Dotchevski.<br>
</div>
<div>
<span class="Apple-tab-span">	</span>* Winapi:&nbsp;Windows API declarations without &lt;windows.h&gt;, for internal Boost use.</div>
<div><br></div>
<div>
<span>For details of what's in the release, see&nbsp;</span><a href="http://www.boost.org/users/history/version_1_56_0.html">http://www.boost.org/users/history/version_1_56_0.html</a><span>.&nbsp;</span><br><span>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.</span><br><br><span>Please download the beta, give it a try, and report any problems you encounter.</span><br><br><span>Thanks,</span><br><br><span>-- The Boost Release Team</span>
</div>
</div>
</div>
</div>
Beman Dawes | 10 Jun 22:19 2014
Picon

Boost Library Incubator recommended by steering committee


The Boost Library Incubator (www.blincubator.com) is a web site conceived, designed, and implemented to alleviate the log-jam of libraries waiting to be reviewed by Boost. It helps new library submitters through the process, encourages development of an initial user base, and accumulates feedback in the form of comments, test results and Boost style reviews.

The Boost Steering Committee has voted to recommend using the Boost Library Incubator as a prelude to getting a library reviewed by Boost.  The Steering Committee recommends libraries currently in the Boost review queue be added to the Incubator by their developers.

The relationship between Boost and the Incubator is purely informal, but there as several things Boosters can do to help make the Incubator a success.  Authors can submit their libraries and respond to feedback.  Users can experiment with submitted libraries and provide feedback on their experience.  WordPress/php developers can contribute enhancements to the Boost Library Incubator implementation.

The steering committee extends its thanks to Robert Ramey for launching the Boost Library Incubator!

--The Boost Steering Committee

<div><div dir="ltr">
<br><div>
<div>The Boost Library Incubator (<a href="http://www.blincubator.com/" target="_blank">www.blincubator.com</a>)
 is a web site conceived, designed, and implemented to alleviate the 
log-jam of libraries waiting to be reviewed by Boost. It helps new 
library submitters through the process, encourages development of an 
initial user base, and accumulates feedback in the form of comments, 
test results and Boost style reviews.<br><br>The
 Boost Steering Committee has voted to recommend using the Boost Library
 Incubator as a prelude to getting a library reviewed by Boost.&nbsp; The 
Steering Committee recommends libraries currently in the Boost review 
queue be added to the Incubator by their developers.<br><br>The
 relationship between Boost and the Incubator is purely informal, but 
there as several things Boosters can do to help make the Incubator a 
success. &nbsp;Authors can submit their libraries and respond to feedback. 
&nbsp;Users can experiment with submitted libraries and provide feedback on 
their experience. &nbsp;WordPress/php developers can contribute enhancements to the Boost Library Incubator implementation.<br><br>
</div>
<div>The steering committee extends its thanks to Robert Ramey for launching the Boost Library Incubator!<br><br>
</div>
<div>--The Boost Steering Committee<br>
</div>
<div><div><br></div></div>
</div>
</div></div>
Glen Fernandes | 10 Jun 00:53 2014
Picon

[boost] [pimpl] Boost.Pimpl review canceled

Hi everyone,

Vladimir has elected to withdraw Boost.Pimpl submission and cancel the
formal review. On behalf of Vladimir, thank you for the feedback
provided in response to the pre-view announcement mail: it was
especially useful to him.

Best,
Glen
Glen Fernandes | 5 Jun 18:32 2014
Picon

Boost.Pimpl upcoming formal review (June 15 - June 24)

The formal review period of Boost.Pimpl by Vladimir Batov is scheduled
to begin later this month, on June 15th, and will conclude on June
24th, and we welcome your participation.

Vladimir's library provides a mechanism for implementing this popular,
and still very relevant, idiom. To borrow his words from the
documentation:

[quote] In the domain of commercial large-scale software development
the following design principles come to the fore:
    - component-based, modular and API-centered design,
    - separation of concerns,
    - implementation hiding,
    - minimization of compilation and component dependencies,
    - consistent and recognizable deployment and implementation patterns,
multi-platform support.

    The Pimpl idiom can help great deal achieving those goals. It is a
simple yet robust programming technique to minimize coupling via the
separation of public interface and private implementation and then
implementation hiding. [/quote]

Please feel encouraged to browse the source code, documentation, and
tests, before the review commences. Any feedback you have prior to the
review period is also very appreciated.

Source:
https://github.com/yet-another-user/boost.pimpl/

Documentation:
http://yet-another-user.github.io/boost.pimpl/

Download:
https://github.com/yet-another-user/boost.pimpl/archive/master.zip

If you would like to submit a review earlier, please provide your
thoughts on the following 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?

As well as information on the following questions:

- 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 most importantly:

- Do you think the library should be accepted as a Boost library?

Best,
Glen
Edward Diener | 2 Jun 00:02 2014

Convert library review manager result

This is my analysis of the 'convert' library review and the result
of whether the convert library should be accepted into Boost.
Please read the entire analysis to understand my reasoning before
reading the result.

I would like to thank all of those who took part in the review and made
comments. This includes Julian Gonggrip, Rob Stewart, Andrzej Krzemienski,
Matus Chochlik, Jeroen Habraken, Erik Nelson, Hartmut Kaiser, Joel De 
Guzman,
Thijs (M.A.) van den Berg, Roland Bock, Gavin Lambert, feverzsj, Paul 
Bristow,
and alex. If I have missed anybody I do apologize. All comments were taken
into account and all comments were intelligent and to the point.

Naturally I would also like to than Vladimir Batov for patiently answering
all comments and explaining and defending his library and his design 
decisions.

For the most part I am going to focus on general issues rather than on the
individuals who made them.

Documentation issues:

The documentation was too focused on explaining the
library as it differed from lexical_cast. Vladimir Batov explained why
this is so but I also agree that the documentation can be better by simply
focusing on what the library provides in terms of functionality. Comments
also mentioned that the current converters are not documented as well as
the could be, and some commenters reflected that knowledge of how a 
particular
converter works, including possible failures using that converter,
is also needed despite the common library interface.

The documentation did not provide enough information
about the use of locales in the library.

The reference section was very limited with not enough explanation. A 
reference
built from doxygen comments in the source files would be better.

A better explanation or example in the documentation for writing one's own
converter was suggested.

Although the Performance section in the documentation was fairly lengthy
some commenters wanted to know why some things could not be tested. 
Others wanted
more information about how convert performance compared to other 
convert-like
implementations.

In general I think most reviewers found the documentation adequate for
understanding how to use the library but lacking in completeness. Vladimir
Batov reflected that if the library were accepted into Boost he would then
create more complete documentation and the above issues could be addressed.

Implementation issues:

As in most reviews most commenters did not look very deeply into the actual
code but were happy to know how to use the library, and this is 
understandable
for a review. There were a few pertinent comments however and I am just 
going
to enumerate them.

All macros should be prefix with BOOST_. My own addition to that is that all
macros should be prefixed with BOOST_CONVERT_ to avoid any conflicts 
with other
libraries.

There should be a jamfile for running the tests. Also some full-blown 
examples
of using the library in a simple program, along with the appropriate 
jamfile,
would be helpful.

Source code should contain spaces, not tabs. This is an easily fixed 
minor issue.

As mentioned before doxygen comments in the public source are the usual 
Boost
way of doing things.

The main header file should be convert.hpp instead of api.h.

Some includes were missing from the printf converter.

Design issues:

In the design of the library is where we have the most varying views. 
The major
issue in discussing the design of the library for those who felt it was 
inadequate
were the comments that using the library was too complicated, that the 
central
function for invoking a conversion should be simpler to use. While all 
suggestions
were well-argued I felt that a number of these differences were merely 
syntactical
issues rather than issues that made the functionality easier to use. The 
main
interface for using the library is:

   convert<output_type>::from(input_value, converter)

Vladimir Batov had asserted during the review that this could be 
simplified further
by removing the need for the 'from::' part of the signature which would 
make the syntax
simpler. Some reviewers did not like the name 'convert' and offered 
substitutions, others
wanted the default value, currently specified as '.value_or(default)', 
to be specified as a direct
input parameter, others wanted the converter itself which is an input 
parameter to be specified
via another syntax. All of these are too me syntactical issues and no 
resolution could
possibly please everybody but it is understandable that different 
reviewers have different
syntactical preferences.

More to the point were some changes in actual functionality. The three 
most important
involved the return value, type requirements for the output type, and 
the use of a default
converter. Considering each in its turn:

1) The return value is some form of 'optional', with the idea of using 
boost::optional
if it meets all the requirements needed by the 'convert' library. A 
number of people
wanted the actual value returned without having to append .value() to 
the convert signature to get it.
They were also concerned with the performance overhead of having to 
create an optional
value as the immediate return value. It was also suggested that while 
the current
convert syntax might be fine, some alternatives directly returning the 
value, for those
who like maximum simplicity, might be possible.

2) The type requirements for the output type are default constructible 
and copy
constructible. A number of reviewers felt that if a non-const reference 
were passed
to the convert function as an output instance then the type requirements 
would not have
to be met. However the type requirements of some of the underlying 
converters might be
affected by this and the documentation does explain how to work around 
the default
constructible requirement, but I still do understand the reasoning 
behind this possibility.

3) A number of reviewers wanted a default converter to be used but there 
was hardly an
agreement on what this default converter should be, some favoring 
lexical_cast, others
favoring stringstream, and no doubt others might want something else. 
Nevertheless
providing a default constructor interface, possible with a macro defined 
a compile time,
seems like it might be doable.

There was further discussion about the actual callable signature for a 
plug-in converter.
Here there was less contention about the interface, which is currently a 
callable with a
signature of:

   template<typename TypeOut, typename TypeIn>
   bool operator()(TypeIn const& value_in, TypeOut& result_out) const;

Vladimir Batov did suggest some possible alternatives and there was a 
discussion
with a number of reviewers about alternatives that seem implementable. 
This also ties
into the concern of some reviewers that it should be straightforward to 
create one's
own converters with minimum restrictions on the input and output types, 
as well as
minimum performance overhead.

Votes:

A number of reviewers made comments but offered no final vote on whether 
or not the
conversion library should be accepted into Boost. Some reviewers offered 
a Yes vote, but
heavily based on changes they want to see. I will attempt to tabulate 
them here:

YES votes:

Christopher Kormanyos
Paul Bristow
Julian Gonggrip ( with some reservations which Vladimir Batove has met 
or may easily meet )
Andrzej Krzemienski
Matus Chochlik

YES, conditionally but otherwise NO if conditions are not met, which the 
current version does not meet]

Jeroen Habraken
Roland Bock
alex

NO

Rob Stewart

Final Decision:

Among those who voted YES conditionally but otherwise NO there was a 
general consensus
including Vladimir Batov, the 'convert' library creator, and some of the 
others that an attempt
could be made to satisfy some of the conditions for simplification 
and/or functionality they
desired.

My decision, based on the votes as I interpret them, is that the convert 
library is ACCEPTED
into Boost. While a perfect design is impossible I believe that the 
design of the library
is an adequate starting point for a general-purpose conversion framework 
and that the design
could change incrementally enough to satisfy some of the qualms of those 
who might not find
it as initially useful as they have hoped, while still maintaining the 
central framework
which Vladimir Batov has created. Furthermore I believe that others have 
reflected that a
general-purpose conversion library would be very useful if it were 
flexible enough to support
plug-in converters created by programmers, as the 'convert' library 
does. I realize that what is
essentially a 5 to 4 vote in favor of the library is not an overwhelming 
consensus by any means
but I feel that 3 of those 4 NO votes are predicated on wishes for 
possible changes to the 'convert' library
which may yet be met before the library gets officially added to an 
upcoming Boost release.

Since I have accepted the library based on the votes and my 
interpretation of the issues I
would like to encourage those who feel that some alternate designs could 
be implemented as part
of the 'convert' library to work with Vladimir Batov, if he is 
agreeable, to add those alternatives
to the library. Nonetheless it is his library and he would be the final 
arbiter of any decisions
reached. I would like to encourage the view, however, that the current 
design is what has been
voted in by others as the 'convert' library so that any changes made to 
it as it is added to
Boost should be incremental additions which minimally change what others 
see as an acceptable library.
Edward Diener | 26 May 18:28 2014

Convert library review period has ended

The review period for the Convert library of Vladimir Batov has ended. 
There is one more potential review, from Rob Stewart, by the end of 
today, as well as any response from Vladimir Batov, I am willing to 
consider as the review manager.

I would like to thank all those who have participated in the review, as 
well as Vladimir Batov for patiently answering reviews and following up 
in discussions.

I will be working on summing up the discussion and votes on whether or 
not Convert should be accepted into Boost, and will issue my final 
decision sometime by the end of this week ( by the end of Sunday June 1 
US Eastern time at the latest ).

Again thanks to all of those who participated in the review and its 
discussions.

Edward Diener
Edward Diener | 14 May 00:07 2014

Boost review of the Convert library is ongoing

The review of the Convert library started Monday, May 12 and goes 
through Wednesday May 21. Many people may have missed the first 
announcement since the mailing lists were held back when the review 
started so I am announcing this again.

The Convert library builds on the boost::lexical_cast original design 
and experience and takes those conversion/transformation-related ideas 
further.

     * to be applicable to a wider range of conversion-related use-cases,
     * to provide a more flexible, extendible and configurable 
type-conversion framework.

The Convert library can be cloned from GitHub at 
https://github.com/yet-another-user/boost.convert. The library follows 
the modular-boost format. Just clone it to modular-boost/libs in the 
'convert' subdirectory and run 'b2 headers' in order to create a link to 
its header file directory in the modular-boost/boost subdirectory.

The library comes with documentation in its top-level index.html or 
doc/html/index.html file. You can also view the documentation online at 
http://yet-another-user.github.io/boost.convert/doc/html/index.html.
The library is by Vladimir Batov and is a second reiteration with a 
greater focus of his library that was reviewed in the past. I am Edward 
Diener and I am again serving as the review manager of the library.

If you have used lexical_cast or, like many C++ programmers, have used 
stringstream to do string-to-type, type-to-string conversions please 
look at this library. We need reviews of whatever point of view before a 
library can even be considered a Boost library.

Comments, questions, and reviews will all be welcome for the library. 
Please try to sum up your review by answering these questions:

     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:

     Do you think the library should be accepted as a Boost library?

As always whether you do or do not feel that the library should be 
accepted into Boost please specify any changes you would like to see for 
the library to be better in your estimation.
Edward Diener | 12 May 03:21 2014

Boost review of the 'convert' library starts tomorrow May 21.

The review of the Convert library starts tomorrow Monday, May 12 and 
goes through Wednesday May 21.

The Convert library builds on the boost::lexical_cast original design 
and experience and takes those conversion/transformation-related ideas 
further.

     * to be applicable to a wider range of conversion-related use-cases,
     * to provide a more flexible, extendible and configurable 
type-conversion framework.

The Convert library can be cloned from GitHub at 
https://github.com/yet-another-user/boost.convert. The library follows 
the modular-boost format. Just clone it to modular-boost/libs in the 
'convert' subdirectory and run 'b2 headers' in order to create a link to 
its header file directory in the modular-boost/boost subdirectory.

The library comes with documentation in its top-level index.html or 
doc/html/index.html file. The library is by Vladimir Batov and is a 
second reiteration with a greater focus of his library that was reviewed 
in the past. I am Edward Diener and I am again serving as the review 
manager of the library.

Comments, questions, and reviews will all be welcome for the library. 
Please try to sum up your review by answering these questions:

     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:

     Do you think the library should be accepted as a Boost library?

As always whether you do or do not feel that the library should be 
accepted into Boost please specify any changes you would like to see for 
the library to be better in your estimation.
Niall Douglas | 4 May 18:00 2014

[TypeIndex 3.0] Review Manager's Report

Dear Boost,

The second round of peer review of proposed Boost.TypeIndex finished 
on Wed 30th, and here is the review manager's report. My thanks to 
the five reviewers who took the time and trouble to submit full 
reviews, plus to everyone else who commented.

Votes regarding acceptance: 

4 voted to accept TypeIndex into Boost immediately.

1 voted to accept into Boost with conditions.

Overall: I recommend immediate acceptance into Boost.

Conditions:

1. No one liked the present boost::typeind namespace, almost anything 
else would be better. I see the namespace has already changed in the 
develop branch to boost::typeindex, so I think this is already 
solved.

Other common comments:

* More than one reviewer mentioned how they liked the docs.

* More than one reviewer expressed a desire for an ability to 
programmatically parse through type specifier strings. I agree with 
Antony that that is another library which isn't TypeIndex (something 
Boost.Spirit based which works directly with mangled symbol string 
representations, representing them as a partial AST - preferably also 
with a libclang compatible backend - would be great, but that is a 
totally different library and TypeIndex 3.x provides extensibility 
for such an additional function).

* More than one reviewer sought some method of preventing link if you 
mix up incompatible uses of TypeIndex and/or with RTTI.

Niall

-- 
Currently unemployed and looking for work in Ireland.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

Attachment (SMime.p7s): application/x-pkcs7-signature, 8 KiB
Dear Boost,

The second round of peer review of proposed Boost.TypeIndex finished 
on Wed 30th, and here is the review manager's report. My thanks to 
the five reviewers who took the time and trouble to submit full 
reviews, plus to everyone else who commented.

Votes regarding acceptance: 

4 voted to accept TypeIndex into Boost immediately.

1 voted to accept into Boost with conditions.

Overall: I recommend immediate acceptance into Boost.

Conditions:

1. No one liked the present boost::typeind namespace, almost anything 
else would be better. I see the namespace has already changed in the 
develop branch to boost::typeindex, so I think this is already 
solved.

Other common comments:

* More than one reviewer mentioned how they liked the docs.

* More than one reviewer expressed a desire for an ability to 
programmatically parse through type specifier strings. I agree with 
Antony that that is another library which isn't TypeIndex (something 
Boost.Spirit based which works directly with mangled symbol string 
representations, representing them as a partial AST - preferably also 
with a libclang compatible backend - would be great, but that is a 
totally different library and TypeIndex 3.x provides extensibility 
for such an additional function).

* More than one reviewer sought some method of preventing link if you 
mix up incompatible uses of TypeIndex and/or with RTTI.

Niall

--

-- 
Currently unemployed and looking for work in Ireland.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

Niall Douglas | 22 Apr 02:15 2014

[gsoc2014] This year's students announced

Dear Boost,

We are pleased to announce that the following eight students will be 
this year's Google Summer of Code for 2014:

1. Anton Bikineev
Mentor: Christopher Kormanyos
Topic:Boost.Math Generalized Hypergeometric Functions

2. Ian Forbes
Mentor: Tim Blechmann
Topic: Boost.Thread Scheduled Executors

3. Louis Dionne
Mentor: Joel Falcou
Topic: A C++11 template metaprogramming library

4. Mark Lingle
Mentor: David Bellot
Topic: Boost.uBlas: Optimization via Smart Templating and a Tree 
Optimizer class

5. Roshan
Mentor: Kyle Lutz
Topic: Expand and Improve Boost.Compute

6. Saksham Maheshwari
Mentor: Stefan Seefeld
Topic: Boost.XML - A Standard XML Library

7. Thaler Benedek
Mentor: Vicente J. Botet Escriba
Topic: Boost.Pipeline

8. Vinícius dos Santos Oliveira
Mentor: Bjorn Reese
Topic: HTTP server on Boost

At US$5,000 funding per student, this represents an investment of 
US$40,000 into Boost by Google this year, for which we are extremely 
grateful. Our thanks to everyone in Google who makes this happen 
every year.

With so few slots available from Google some very good candidates and 
proposals could not be selected, so if you were not selected this 
year, better luck next year (remember to come early!). 
Congratulations to the students who did make it, and our collective 
thanks go to the primary mentors above for taking the time this 
summer, as well to the secondary mentors not listed above as well as 
everyone who helped out with the proposal review and the ranking and 
voting this year.

Niall & Boris

--- 
Boost C++ Libraries Google Summer of Code 2014 admin
https://svn.boost.org/trac/boost/wiki/SoC2014

Attachment (SMime.p7s): application/x-pkcs7-signature, 8 KiB
Dear Boost,

We are pleased to announce that the following eight students will be 
this year's Google Summer of Code for 2014:

1. Anton Bikineev
Mentor: Christopher Kormanyos
Topic:Boost.Math Generalized Hypergeometric Functions

2. Ian Forbes
Mentor: Tim Blechmann
Topic: Boost.Thread Scheduled Executors

3. Louis Dionne
Mentor: Joel Falcou
Topic: A C++11 template metaprogramming library

4. Mark Lingle
Mentor: David Bellot
Topic: Boost.uBlas: Optimization via Smart Templating and a Tree 
Optimizer class

5. Roshan
Mentor: Kyle Lutz
Topic: Expand and Improve Boost.Compute

6. Saksham Maheshwari
Mentor: Stefan Seefeld
Topic: Boost.XML - A Standard XML Library

7. Thaler Benedek
Mentor: Vicente J. Botet Escriba
Topic: Boost.Pipeline

8. Vinícius dos Santos Oliveira
Mentor: Bjorn Reese
Topic: HTTP server on Boost

At US$5,000 funding per student, this represents an investment of 
US$40,000 into Boost by Google this year, for which we are extremely 
grateful. Our thanks to everyone in Google who makes this happen 
every year.

With so few slots available from Google some very good candidates and 
proposals could not be selected, so if you were not selected this 
year, better luck next year (remember to come early!). 
Congratulations to the students who did make it, and our collective 
thanks go to the primary mentors above for taking the time this 
summer, as well to the secondary mentors not listed above as well as 
everyone who helped out with the proposal review and the ranking and 
voting this year.

Niall & Boris

--- 
Boost C++ Libraries Google Summer of Code 2014 admin
https://svn.boost.org/trac/boost/wiki/SoC2014

Ahmed Charles | 21 Apr 03:55 2014

Boost.Align review results

The review of the proposed Boost.Align library ended on April 20, 2014. The result is: Accepted with conditions.

Glen and I would like to thank everyone for contributing to the review for Boost.Align. either with a review
or comments in the discussions.

The summary of formal votes is as follows (alphabetical order):
 
Andrey Semashev - Yes (conditional)
Antony Polukhin - Yes (conditional)
Bjorn Reese     - Yes
Lars Viklund    - Yes
Michael Spencer - Yes
 
For a total of 5 votes for acceptance and 0 votes for rejection.
 
The conditional acceptance is based on the quality of documentation, as the feedback given on code and
design has already been addressed. The conditions below are agreeable to the author:

1. QuickBook documentation should be used, following typical Boost documentation structure.
2. Additional examples should be used to make the understanding/use of the library easier.
3. Additional minor comments from the reviews should be addressed.

I would like to thank Glen for making this an easy first review manager experience and I look forward to
reviewing other libraries in the future.
 		 	   		  

Gmane