Ron Garcia | 30 Aug 13:09 2014
Picon

Review Wizard Status Report for August 2014


==============================================
Review Wizard Status Report for August 2014
==============================================

News
====

1. Fiber Accepted Provisionally. January 2014.
2. Align Accepted. April 2014.
3. TypeIndex Accepted. May 2014.
4. Convert Accepted. June 2014.
5. Boost 1.56 Released -- New Libraries: Align, TypeIndex

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

The following libraries have review managers, but have not yet been
scheduled for review:

* Range Extensions - added May 2012; review manager: Neil Groves.

The following libraries have been accepted to Boost, but have not yet
been integrated into Boost Git:

* Contract - accepted September 2012; author: Lorenzo Caminiti.

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

(Continue reading)

Steven Watanabe | 21 Aug 16:07 2014
Picon

[review] Formal review period for VMD library begins today, Aug 21, and ends Sat, Aug 30

AMDG

The formal review of the VMD library by Edward Diener
starts today, Aug 21st and is scheduled to continue until Aug 30th.

About VMD
===============

The Variadic Macro Data library is a library
of variadic macros which enhance the functionality in
the Boost preprocessor library ( Boost PP ). The main
focus of the library is the parsing/identifying of a subset
of C++ preprocessor data types and of all Boost PP data types.
This allows enhanced preprocessor metaprogramming based on the type of
macro input. The library may also be seen as a repository for
future enhancements to the Boost PP library functionality using
variadic macros.

Where to get it
===============

The library is available on github at
https://github.com/eldiener/variadic_macro_data

Review guidelines
=================

Reviews should be submitted to the developer list
(boost <at> lists.boost.org), with '[vmd]' in the subject. Or if you
don't wish to for some reason, you can send them privately to me. If
(Continue reading)

Marshall Clow | 7 Aug 19:54 2014
Picon

Boost 1.56.0 has been released

Release 1.56.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 and numerous enhancements and bug fixes for existing libraries.

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

=== New Libraries ===
• Align: Memory alignment functions, allocators, and adaptors, from Glen Fernandes.
• Type_Index: Runtime/Compile time copyable type info, from Antony Polukhin.


For details, including download links, see http://www.boost.org/users/news/version_1.56.0

You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.56.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

  Vladimir Prus
  Rene Rivera
  Marshall Clow
  Eric Niebler
  Daniel James
  Beman Dawes
<div>
<div>
<span>Release 1.56.0 of the Boost C++ Libraries is now available.</span><br><br><span>These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications.&nbsp;</span><br><span>The Boost license encourages both commercial and non-commercial use.</span><br><br><span>This release contains one new library and numerous enhancements and bug fixes for existing libraries.</span><br><br>=== Modularization ===</div>
<div>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. The new modules are:<br><br><div>
<span class="Apple-tab-span">	</span>&bull; Assert:<span class="Apple-tab-span">	</span>Customizable assert macros. Maintained by Peter Dimov.<br>
</div>
<div>
<span class="Apple-tab-span">	</span>&bull; Core:&nbsp;<span class="Apple-tab-span">	</span>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>&bull; Lexical_Cast:<span class="Apple-tab-span">	</span>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>&bull; Throw_Exception:<span class="Apple-tab-span">	</span>A common infrastructure for throwing exceptions from Boost libraries, from Emil Dotchevski.<br>
</div>
<div>
<span class="Apple-tab-span">	</span>&bull; Winapi:<span class="Apple-tab-span">	</span>Windows API declarations without &lt;windows.h&gt;, for internal Boost use.<br>
</div>
<div><br></div>=== New Libraries ===<br><div>
<span class="Apple-tab-span">	</span>&bull; Align:<span class="Apple-tab-span">	</span>Memory alignment functions, allocators, and adaptors, from Glen Fernandes.<br>
</div>
<div>
<span class="Apple-tab-span">	</span>&bull; Type_Index:<span class="Apple-tab-span">	</span>Runtime/Compile time copyable type info, from Antony Polukhin.<br>
</div>
<br><br><span>For details, including download links, see&nbsp;</span><a href="http://www.boost.org/users/news/version_1.56.0">http://www.boost.org/users/news/version_1.56.0</a><br><br><span>You can also download directly from SourceForge:&nbsp;</span><a href="http://sourceforge.net/projects/boost/files/boost/1.56.0/">http://sourceforge.net/projects/boost/files/boost/1.56.0/</a><br><br><span>To install this release on your system, see&nbsp;</span><a href="http://www.boost.org/doc/libs/release/more/getting_started/index.html">http://www.boost.org/doc/libs/release/more/getting_started/index.html</a><br><br><span>Thanks,</span><br><br><span>--The Boost release team</span><br><br><span>&nbsp;&nbsp;Vladimir Prus</span><br><span>&nbsp;&nbsp;Rene Rivera</span><br><span>&nbsp;&nbsp;Marshall Clow</span><br><span>&nbsp;&nbsp;Eric Niebler</span><br><span>&nbsp;&nbsp;Daniel James</span><br><span>&nbsp;&nbsp;Beman Dawes</span>
</div>
</div>
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.

Gmane