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

(Continue reading)

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.
 		 	   		  
Niall Douglas | 20 Apr 20:14 2014

[typeindex v3.0] Peer review begins Mon 21st ends Wed 30th

Dear Boost,

A second round of community review begins for proposed 
Boost.TypeIndex on Mon 21st, lasting ten days. I should apologise as 
it's my fault for starting another peer review straight after 
Boost.Align ends, however I was busy as Google Summer of Code admin 
until today, and I will be preparing to talk at C++ Now straight 
after this review ends. I hope that this doesn't affect the 
community's willingness to contribute to the review.

Reminder of the report from the last TypeIndex v2.1 review: 
https://groups.google.com/forum/#!topic/boost-list/TeiSdkRkUF0

Reminder of the original peer review announcement: 
http://boost.2283326.n4.nabble.com/TypeIndex-Peer-review-period-for-li
brary-acceptance-begins-ending-Thurs-21st-Nov-td4654788.html

Source code: https://github.com/apolukhin/type_index/zipball/master

Github: https://github.com/apolukhin/type_index

Documentation: http://apolukhin.github.com/type_index/index.html

Changes in TypeIndex v3.0 since v2.1 (from my own review of it):

1. Documentation is hugely improved over v2.1, lots of side by side 
examples illustrating the differences and similarities.

2. You can now create your own custom type indices using an 
extensible framework.
(Continue reading)

Ahmed Charles | 28 Mar 03:50 2014

Boost.Align review announcement

Hi everyone,

The review of Boost.Align by Glen Fernandes is scheduled from Friday, April 11th to April 20th. 

Source:
http://github.com/glenfe/align

Documentation:
http://glenfe.github.io/align

Description:
This library provides function align for implementations which do not have the C++11 standard library
align function available.It
 provides allocation functions aligned_alloc and aligned_free as their 
functionality is not yet available in the C++ standard library. They use
 platform specific functions, if available, or use standard library 
functions in conjunction with align.It
 provides C++ allocators, class templates aligned_allocator and 
aligned_allocator_adaptor, which respect alignment. The first uses 
aligned_alloc and aligned_free while the second uses the allocator in 
conjunction with align.It also provides function is_aligned to test the alignment of a pointer.
Rationale:
C++11
 added the ability to specify increased alignment (over-alignment) for 
class types. Unfortunately, ::operator new allocation functions, new 
expressions, and the default allocator, std::allocator, do not support 
dynamic memory allocation of over-aligned data.
The aligned_alloc function can be used in place of ::operator new to specify the alignment of the memory
allocated.The aligned_allocator class template can be used in place of std::allocator as an
alignment-aware default allocator.The aligned_allocator_adaptor class template can be used to adapt
(Continue reading)

Niall Douglas | 24 Mar 22:07 2014

[GSoC 14] Request community to rank proposals

Dear Boost Community,

The Google Summer of Code 2014 proposals for Boost are in, and we 
would deeply appreciate the community's help in ranking the proposals 
according to merit before the 1st of April.

To vote, the process is easy:

1. Go to this page 
https://www.google-melange.com/gsoc/homepage/google/gsoc2014 and 
click the "Log in" button under Mentors and Administrators.

2. Now click "Create Profile" on the same page. Note that even if you 
registered last year, you must register again in 2014. Fill in the 
form. Note that after submitting it drops you at "Edit Profile", 
which is confusing.

3. Click "My Dashboard", then "Connect with organisations".

4. Choose "Boost C++ Libraries".

5. In the message box, write this: "I am a member of the Boost 
community and the email(s) I normally post to boost mailing lists 
with is <email>" filling in the email address(es) you normally use to 
post to boost mailing lists. This lets us verify that you are indeed 
a long standing member of the Boost community.

6. Once we approve your request, you will get an email with the 
subject "Welcome as organisation member". You can now return to the 
Dashboard on the GSoC website where there will be a new item 
(Continue reading)

Joel Falcou | 15 Feb 12:34 2014
Picon

NT² 3.0 and Boost.SIMD - Stable release

The first stable release of the 3.x series of MetaScale’s open-source 
software is available: NT² 3.0. It also includes its spin-off project, 
Boost.SIMD (not yet a Boost library). Many Issues have been closed since 
last beta. The main focus of this release cycle was to fix performances 
issues and to stabilize some parts of the API.

Next step will be to separate NT2 and Boost.SIMD into separate 
repositories, thus making one more step toward Boost.SIMD submission 
into review.

[ http://www.metascale.org/nt%C2%B2-3-0-and-boost-simd ]

*Changes & Bug Fixes:*

  - Major performance improvements in both libraries
  - Added experimental support for the HPX runtime for parallelization 
on shared memory systems
  - Optimizations of many elemental functions, in particuler log/ex, 
frexp/ldexp and cbrt
  - More advanced shuffle pattern recognition for SIMD
  - Fixed issues with Visual Studio 2013
  - More functions are force-inlined to ensure good performance
  - New functions for conversion between types and mixing of vectors of 
different sizes
  - Demo applications usable as benchmarks
  - Better handling of errors when an unsupported function is called
  - New API for custom memory allocators

Full changelog is available at 
https://github.com/MetaScale/nt2/releases/tag/3.0.0.
(Continue reading)

Niall Douglas | 8 Feb 04:15 2014

Attn: We need GSoC 2014 mentors for Boost!

Dear Boost community,

We are now just five days away from the closing date for Google 
Summer of Code 2014 registration. Last year's GSoC was a huge 
success, with Google funding work on Boost to the tune of $35,000 and 
paying over $8,000 in costs for three representatives of Boost to 
attend the GSoC mentor's summit at Google HQ.

As part of filling in our application for 2014, we must supply to 
Google a list of potential GSoC mentors and potential GSoC projects 
for summer 2014. We do NOT want a repeat of 2012 when our application 
was rejected due to an insufficiently long list of prospective 
mentors and projects! At the time of writing, we have just *eight* 
prospective mentors, and we need more to be sure of being approved by 
Google!

Therefore, if you think yourself able to mentor a student doing some 
work on Boost this summer, *please* consider adding a description of 
the proposed work item and your name to the list at 
https://svn.boost.org/trac/boost/wiki/SoC2014.

If you want to know more about mentoring a Google Summer of Code 
funded student work before you nominate yourself, please feel free to 
ask on the main Boost developers mailing list boost <at> lists.boost.org. 
Thank you in advance for your time.

Niall Douglas (Boost Google Summer of Code admin)
Boris Schäling (Boost Google Summer of Code backup admin)

(Continue reading)

Nat Goodspeed | 6 Jan 14:07 2014

Boost.Fiber review January 6-15

Hi all,

The review of Boost.Fiber by Oliver Kowalke begins today, Monday January 6th, and closes Wednesday January 15th.

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

About the library:

Boost.Fiber provides a framework for micro-/userland-threads (fibers) scheduled cooperatively. The API contains classes and functions to manage and synchronize fibers similar to Boost.Thread. Each fiber has its own stack.

A fiber can save the current execution state, including all registers and CPU flags, the instruction pointer, and the stack pointer and later restore this state. The idea is to have multiple execution paths running on a single thread using a sort of cooperative scheduling (versus threads, which are preemptively scheduled). The running fiber decides explicitly when it should yield to allow another fiber to run (context switching). Boost.Fiber internally uses coroutines from Boost.Coroutine; the classes in this library manage, schedule and, when needed, synchronize those coroutines. A context switch between threads usually costs thousands of CPU cycles on x86, compared to a fiber switch with a few hundred cycles. A fiber can only run on a single thread at any point in time.

docs: http://olk.github.io/libs/fiber/doc/html/
git: https://github.com/olk/boost-fiber
src: http://ok73.ok.funpic.de/boost.fiber.zip

The documentation has been moved to another site; see the link above.
If you have already downloaded the source, please refresh it; Oliver has added some new material.

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

Please always state in your review whether you think the library should be accepted as a Boost library!

Additionally please consider giving feedback on the following general topics:

- What is your evaluation of the design?
- What is your evaluation of the implementation?
- What is your evaluation of the documentation?
- What is your evaluation of the potential usefulness of the library?
- Did you try to use the library? With what compiler? Did you have any problems?
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
- Are you knowledgeable about the problem domain?

Nat Goodspeed
Boost.Fiber Review Manager
________________________________
<div><div dir="ltr">
<div>
<div>Hi all,<br><br>The review of Boost.Fiber by Oliver Kowalke begins today, Monday January 6th, and closes Wednesday January 15th.<br><br>-----------------------------------------------------<br><br>About the library:<br><br>Boost.Fiber provides a framework for micro-/userland-threads (fibers) scheduled cooperatively. The API contains classes and functions to manage and synchronize fibers similar to Boost.Thread. Each fiber has its own stack.<br><br>A fiber can save the current execution state, including all registers and CPU flags, the instruction pointer, and the stack pointer and later restore this state. The idea is to have multiple execution paths running on a single thread using a sort of cooperative scheduling (versus threads, which are preemptively scheduled). The running fiber decides explicitly when it should yield to allow another fiber to run (context switching). Boost.Fiber internally uses coroutines from Boost.Coroutine; the classes in this library manage, schedule and, when needed, synchronize those coroutines. A context switch between threads usually costs thousands of CPU cycles on x86, compared to a fiber switch with a few hundred cycles. A fiber can only run on a single thread at any point in time.<br><br>docs: <a href="http://olk.github.io/libs/fiber/doc/html/">http://olk.github.io/libs/fiber/doc/html/</a><br>git: <a href="https://github.com/olk/boost-fiber">https://github.com/olk/boost-fiber</a><br>src: <a href="http://ok73.ok.funpic.de/boost.fiber.zip">http://ok73.ok.funpic.de/boost.fiber.zip</a><br><br>
</div>The documentation has been moved to another site; see the link above.<br>
</div>If you have already downloaded the source, please refresh it; Oliver has added some new material.<br><div><div>
<br>---------------------------------------------------<br><br>Please always state in your review whether you think the library should be accepted as a Boost library!<br><br>Additionally please consider giving feedback on the following general topics:<br><br>- What is your evaluation of the design?<br>
- What is your evaluation of the implementation?<br>- What is your evaluation of the documentation?<br>- What is your evaluation of the potential usefulness of the library?<br>- Did you try to use the library? With what compiler? Did you have any problems?<br>
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?<br>- Are you knowledgeable about the problem domain?<br><br>Nat Goodspeed<br>Boost.Fiber Review Manager<br>________________________________<br>
</div></div>
</div></div>
Hartmut Kaiser | 9 Dec 02:11 2013
Picon

C++Now 2014: Call for Submissions, Updated deadlines

Updated submission dates! Please see below!

==============================================
C++ Now Conference 2014
Aspen CO, USA, May 12-17, 2014, www.cppnow.org
==============================================

For the full announcement online, please see here: 
http://cppnow.org/2013/10/21/2014-call-for-submissions/

Call for Submissions
--------------------
We invite you to submit session proposals to the 3rd annual C++Now 
Conference (Aspen CO, USA, May 12-17, 2014).

Building upon the resounding success of C++Now 2013 and five years 
of BoostCon, C++Now 2014 will present leading speakers from the 
whole C++ community.

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.
At C++Now 2014 we would like to focus on the now established C++11 
standard and the new, upcoming C++14 and how those standards are and 
will shape C++'s future. However, by no means is this intended to 
restrict the topics of proposals we hope to see. Any other topic related 
to C++ as outlined below is perfectly fine for submission.

Important dates
---------------
New proposal submissions due: December 22th, 2013. 
Proposals decisions sent (tentative program available): February 15th, 2014.
Fully scheduled program available: February 28th, 2014.

Best Presentation Awards
------------------------
We know how much effort it takes to prepare talks for our conference. For 
this reason we will award the best 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/14 and how it changes life for users and library writers
 * General tutorial sessions on C++11/14, the C++11/14 Standards library, 
   and one or more Boost libraries
 * Parallelism in the new C++11/14 standard
 * Parallel, distributed and GPGPU topics relating to C++
 * 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 C++ 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 or C++14, 
                Boost and users.
Panels          Panels feature three or four people presenting their 
                ideas and experiences relating to C++11 or C++14 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
                or C++14 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 Presentations 
                These were introduced at BoostCon 2008, and were a great 
                success. They are short (30 minute) sessions, focusing on
                tips on usage and design. In addition, we're looking to 
                uncover the hidden design gems in Boost libraries. 
Tool Vendors Presentations
                We actively encourage tool vendors and ISP's to submit 
                proposals for a special Tool Vendors Session Track aimed 
                at products related to Boost and C++ (compilers, 
                libraries, tools, etc.).

Other formats may also be of interest. Don't hold back a proposal just 
because it doesn't fit into a pigeonhole.

Submitting a proposal
---------------------
Standard sessions are 90 minutes. You may submit a proposal for fractions 
or multiples of 90-minutes. Fractional proposals will be grouped into 
90 minute sessions covering related topics. Longer sessions, such as 
tutorials and classes, will be assigned 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.
 * A photo of about 150 x 150
 * Your public contact information (twitter handle, blog, website,
   google plus, etc.)
 * 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=cppnow2014. 
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 2014 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 
cppnow2014 <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)
Joel Falcou, email: joel.falcou <at> lri.fr (Program Committee Co-Chair)
Jon Kalb, , email: jon <at> kalbweb.com (Conference Chair)
Dave Abrahams, dave <at> boostpro.com (Conference Chair)
On behalf of the conference organizers

Niall Douglas | 24 Nov 23:29 2013

Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th – 21st 2013

Please let me know as soon as possible any errata, missing credits etc.

Niall

 

Boost Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th – 21st 2013

This report is the first edition, dated Sunday 24th November 2013. The review manager was Niall Douglas http://www.nedprod.com/.

Source: https://github.com/apolukhin/type_index/zipball/master

Documentation: http://apolukhin.github.com/type_index/index.html

Peer review discussion detail: http://boost.2283326.n4.nabble.com/TypeIndex-Peer-review-period-for-library-acceptance-begins-ending-Thurs-21st-Nov-tt4654788.html

My thanks to the Boost members whose peer review makes up this report: Robert Ramey, Vicente J. Botet Escriba, Gavin Lambert, Andrey Semashev, Steven Watanabe, pfultz2, Mathieu Champlon, Joël Lamotte Klaim, Rob Stewart, Jan Herrmann, Tony Van Eerd.

Contents:

·         Summary of consensus from peer review ......................................................................................................... 1

·         My recommendation to the library author and the Review Wizards ................................................................ 3

Summary of consensus from peer review:

The consensus feedback was to accept TypeIndex after substantial modifications. There were two recommendations of rejection due to how substantial such modifications would need to be (i.e. a request for a second round of peer review with a new implementation).

Note that my personal opinion based on post-review reflection is written in [square bracketed italics].

·         Many seemed to feel that a boost::type_info’s member function API, where identically named to that of std::type_info member function API, ought to have identical compile-time effects. This implied that missing member function APIs, or other compile time errors for missing or incomplete functionality, would be okay but if name() returns some const char *, then any const char * so long as it meets the C++ standard is okay.

 

[I think there are three use cases for a type_info like substitute: (i) as a lightest possible weight, non-RTTI requiring minimal type_info which can have any API it likes and ought to not be directly substitutable for std::type_info or std::type_index (ii) as a compile-time substitute for std::type_info in that it will compile without third party code modification, but may not produce reliable code due to not returning exactly the same values as std::type_info (iii) as a runtime substitute for std::type_info in that it will require code to be “ported” to it due to having a breaking API, but thereafter produces reliable code. I’ll be very blunt in saying that (ii) is a bad idea in my opinion, and (iii) is valuable but out of scope enhancement which could be added as a separate class after peer review. In my opinion, (i) is where we ought to focus, and I would recommend that the lightest possible weight type_info replacement be deliberately compile-time incompatible with std::type_info (where output is not identical to std::type_info) to force porting code to it so authors are not lazy.]

 

·         A large minority seemed to feel that a boost::type_info’s member function API, where identically named to that of std::type_info member function API, ought to have identical run-time outcomes. Most specifically, this would mean that member functions e.g. name() would return exactly what std::type_info’s name() does, even if for example name() returns a std::string instead of a const char * as would be necessary in pre-C++11 compilers.

 

[This is really use case (iii) in the previous item.]

 

·         It was mentioned that it should be possible to optionally specialise std::hash<> for type_info for optional seamless use in hash taking containers.

 

·         Some felt that implementation-specific std::type_info quirks ought to be replicated. Others felt they should not, and a portable interface which works identically on all platforms is preferred.

 

[This is really use case (iii) in the previous item.]

 

·         boost::type_info is currently initialised via a static cast from a std::type_info when RTTI is available. This is undefined behaviour, and some felt this to be a showstopper. I (Niall Douglas) looked into this more deeply due to its seriousness, and found that because most STL implementations define std::type_info with a virtual function table, the undefined behaviour static cast would cause dynamic_cast on a boost::type_info instance to misoperate.

 

[I believe the RTTI induced misoperation to indeed be a showstopper, and that this use of undefined behaviour to reduce code bloat is an unsafe optimisation. A much lighter weight non-direct-substitute for std::type_info ought to be as code bloat parsimonious as is possible, while its lack of non-explicit interoperation ability with std::type_info ought to allow avoidance of needing any UB tricks.]

 

·         Some felt that any use of implied boost::type_info ought to be explicitly written as boost::type_info instead of relying on namespace lookup, as the name similarity to std::type_info may introduce confusion.

 

[I agree]

 

·         It was mentioned that some function-local static data members are initialised in a thread unsafe way.

 

[For information I have to hand a very lightweight BOOST_BEGIN_MEMORY_TRANSACTION() implementation ideal for this purpose. We could submit it to Boost.Detail and then everyone could use it?]

 

·         Magic macros such as __PRETTY_FUNCTION__ ought to not be referenced outside of a function as they don’t technically exist there. Checks for their existence ought to be within a function.

 

·         It was requested that a boost::type_id<> which takes some unknown variable instance as a parameter and therefore allows the compiler to deduce the type of the variable as the boost::type_index<T> type would be valuable.

 

·         A mechanism for programming compile-time logic with class inheritance trees such that inheritance can be determined at compile-time with RTTI disabled was requested.


 

My recommendation to the library author and the Review Wizards:

·         In my opinion Antony ought to make TypeIndex v3 quite literally a very lightweight container of some unknown, but known to be uniquely identifying for some type, static const char * string. I think its class type and its list of member functions ought to be deliberately compile-time incompatible with std::type_info to force authors to upgrade their code. A conversion member function ought to be able to synthesise a corresponding std::type_info using typeid() from some boost::type_index<T>, but that’s about it. I would even, personally speaking, go so far as to only provide a boost::type_index and no corresponding boost::type_info, especially if the boost::type_id<T>() function can return a const boost::type_index<T>& and therefore can be used as a static const lref, or copy constructed from it etc.

 

A suggested name() member function replacement which correctly breaks out the multiple confounding uses of std::type_info::name() into each of their three use cases (and which intentionally causes any use of name() to fail to compile) might be:

Bear in mind that user code can always subclass boost::type_index and add their own name() implementation based on one or more of the above new member functions.

 

·         In other words, here I think “less is more” in every way you look at it. I think a slimmer less heavy TypeIndex would be a superior solution.

 

·         I request the Review Wizards to allow Antony some time to make the changes to produce a v3 of the library, and then to allow TypeIndex v3 a Fast Track Review of five days to ensure the Boost community is happy and that its feedback has been incorporated. It was asked during peer review that such a five day period please include a weekend. I would be happy to serve as review manager again if requested.

Niall Douglas
Waterloo, Canada, November 2013

 

<div><div class="WordSection1">
<p class="MsoPlainText">Please let me know as soon as possible any errata, missing credits etc.<p></p></p>
<p class="MsoPlainText">Niall<p></p></p>
<p class="MsoPlainText"><p>&nbsp;</p></p>
<div><p class="MsoTitle">Boost Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th &ndash; 21st 2013<p></p></p></div>
<p class="MsoNormal">This report is the first edition, dated Sunday 24th November 2013. The review manager was Niall Douglas <a href="http://www.nedprod.com/">http://www.nedprod.com/</a>.<p></p></p>
<p class="MsoNormal">Source: <a href="https://github.com/apolukhin/type_index/zipball/master">https://github.com/apolukhin/type_index/zipball/master</a><p></p></p>
<p class="MsoNormal">Documentation: <a href="http://apolukhin.github.com/type_index/index.html">http://apolukhin.github.com/type_index/index.html</a><p></p></p>
<p class="MsoNormal">Peer review discussion detail: <a href="http://boost.2283326.n4.nabble.com/TypeIndex-Peer-review-period-for-library-acceptance-begins-ending-Thurs-21st-Nov-tt4654788.html">http://boost.2283326.n4.nabble.com/TypeIndex-Peer-review-period-for-library-acceptance-begins-ending-Thurs-21st-Nov-tt4654788.html</a> <p></p></p>
<p class="MsoNormal">My thanks to the Boost members whose peer review makes up this report: Robert Ramey, Vicente J. Botet Escriba, Gavin Lambert, Andrey Semashev, Steven Watanabe, pfultz2, Mathieu Champlon, Jo&euml;l Lamotte Klaim, Rob Stewart, Jan Herrmann, Tony Van Eerd.<p></p></p>
<h1>Contents:<p></p>
</h1>
<p class="MsoListParagraphCxSpFirst"><span><span>&middot;<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span>Summary of consensus from peer review ......................................................................................................... 1<p></p></p>
<p class="MsoListParagraphCxSpLast"><span><span>&middot;<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span>My recommendation to the library author and the Review Wizards ................................................................ 3<p></p></p>
<h1>Summary of consensus from peer review:<p></p>
</h1>
<p class="MsoNormal">The consensus feedback was to accept TypeIndex after substantial modifications. There were two recommendations of rejection due to how substantial such modifications would need to be (i.e. a request for a second round of peer review with a new implementation).<p></p></p>
<p class="MsoNormal">Note that my personal opinion based on post-review reflection is written in [square bracketed italics].<p></p></p>
<p class="MsoListParagraphCxSpFirst"><span><span>&middot;<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span>Many seemed to feel that a boost::type_info&rsquo;s member function API, where identically named to that of std::type_info member function API, ought to have identical compile-time effects. This implied that missing member function APIs, or other compile time errors for missing or incomplete functionality, would be okay but if name() returns some const char *, then any const char * so long as it meets the C++ standard is okay.<p></p></p>
<p class="MsoListParagraphCxSpMiddle"><p>&nbsp;</p></p>
<p class="MsoListParagraphCxSpMiddle">[I think there are three use cases for a type_info like substitute: (i) as a lightest possible weight, non-RTTI requiring minimal type_info which can have any API it likes and ought to not be directly substitutable for std::type_info or std::type_index (ii) as a compile-time substitute for std::type_info in that it will compile without third party code modification, but may not produce reliable code due to not returning exactly the same values as std::type_info (iii) as a runtime substitute for std::type_info in that it will require code to be &ldquo;ported&rdquo; to it due to having a breaking API, but thereafter produces reliable code. I&rsquo;ll be very blunt in saying that (ii) is a bad idea in my opinion, and (iii) is valuable but out of scope enhancement which could be added as a separate class after peer review. In my opinion, (i) is where we ought to focus, and I would recommend that the lightest possible weight type_info replacement be deliberately compile-time incompatible with std::type_info (where output is not identical to std::type_info) to force porting code to it so authors are not lazy.]<p></p></p>
<p class="MsoListParagraphCxSpMiddle"><p>&nbsp;</p></p>
<p class="MsoListParagraphCxSpMiddle"><span><span>&middot;<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span>A large minority seemed to feel that a boost::type_info&rsquo;s member function API, where identically named to that of std::type_info member function API, ought to have identical run-time outcomes. Most specifically, this would mean that member functions e.g. name() would return exactly what std::type_info&rsquo;s name() does, even if for example name() returns a std::string instead of a const char * as would be necessary in pre-C++11 compilers.<p></p></p>
<p class="MsoListParagraphCxSpMiddle"><p>&nbsp;</p></p>
<p class="MsoListParagraphCxSpMiddle">[This is really use case (iii) in the previous item.]<p></p></p>
<p class="MsoListParagraphCxSpMiddle"><p>&nbsp;</p></p>
<p class="MsoListParagraphCxSpMiddle"><span><span>&middot;<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span>It was mentioned that it should be possible to optionally specialise std::hash&lt;&gt; for type_info for optional seamless use in hash taking containers.<p></p></p>
<p class="MsoListParagraphCxSpMiddle"><p>&nbsp;</p></p>
<p class="MsoListParagraphCxSpMiddle"><span><span>&middot;<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span>Some felt that implementation-specific std::type_info quirks ought to be replicated. Others felt they should not, and a portable interface which works identically on all platforms is preferred.<p></p></p>
<p class="MsoListParagraphCxSpMiddle"><p>&nbsp;</p></p>
<p class="MsoListParagraphCxSpMiddle">[This is really use case (iii) in the previous item.]<p></p></p>
<p class="MsoListParagraphCxSpMiddle"><p>&nbsp;</p></p>
<p class="MsoListParagraphCxSpMiddle"><span><span>&middot;<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span>boost::type_info is currently initialised via a static cast from a std::type_info when RTTI is available. This is undefined behaviour, and some felt this to be a showstopper. I (Niall Douglas) looked into this more deeply due to its seriousness, and found that because most STL implementations define std::type_info with a virtual function table, the undefined behaviour static cast would cause dynamic_cast on a boost::type_info instance to misoperate.<p></p></p>
<p class="MsoListParagraphCxSpMiddle"><p>&nbsp;</p></p>
<p class="MsoListParagraphCxSpMiddle">[I believe the RTTI induced misoperation to indeed be a showstopper, and that this use of undefined behaviour to reduce code bloat is an unsafe optimisation. A much lighter weight non-direct-substitute for std::type_info ought to be as code bloat parsimonious as is possible, while its lack of non-explicit interoperation ability with std::type_info ought to allow avoidance of needing any UB tricks.]<p></p></p>
<p class="MsoListParagraphCxSpMiddle"><p>&nbsp;</p></p>
<p class="MsoListParagraphCxSpMiddle"><span><span>&middot;<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span>Some felt that any use of implied boost::type_info ought to be explicitly written as boost::type_info instead of relying on namespace lookup, as the name similarity to std::type_info may introduce confusion.<p></p></p>
<p class="MsoListParagraphCxSpMiddle"><p>&nbsp;</p></p>
<p class="MsoListParagraphCxSpMiddle">[I agree]<p></p></p>
<p class="MsoListParagraphCxSpMiddle"><p>&nbsp;</p></p>
<p class="MsoListParagraphCxSpMiddle"><span><span>&middot;<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span>It was mentioned that some function-local static data members are initialised in a thread unsafe way.<p></p></p>
<p class="MsoListParagraphCxSpMiddle"><p>&nbsp;</p></p>
<p class="MsoListParagraphCxSpMiddle">[For information I have to hand a very lightweight BOOST_BEGIN_MEMORY_TRANSACTION() implementation ideal for this purpose. We could submit it to Boost.Detail and then everyone could use it?]<p></p></p>
<p class="MsoListParagraphCxSpMiddle"><p>&nbsp;</p></p>
<p class="MsoListParagraphCxSpMiddle"><span><span>&middot;<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span>Magic macros such as __PRETTY_FUNCTION__ ought to not be referenced outside of a function as they don&rsquo;t technically exist there. Checks for their existence ought to be within a function.<p></p></p>
<p class="MsoListParagraphCxSpMiddle"><p>&nbsp;</p></p>
<p class="MsoListParagraphCxSpMiddle"><span><span>&middot;<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span>It was requested that a boost::type_id&lt;&gt; which takes some unknown variable instance as a parameter and therefore allows the compiler to deduce the type of the variable as the boost::type_index&lt;T&gt; type would be valuable.<p></p></p>
<p class="MsoListParagraphCxSpMiddle"><p>&nbsp;</p></p>
<p class="MsoListParagraphCxSpLast"><span><span>&middot;<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span>A mechanism for programming compile-time logic with class inheritance trees such that inheritance can be determined at compile-time with RTTI disabled was requested.<p></p></p>
<span><br clear="all"></span><p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<h1>My recommendation to the library author and the Review Wizards:<p></p>
</h1>
<p class="MsoListParagraphCxSpFirst"><span><span>&middot;<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span>In my opinion Antony ought to make TypeIndex v3 quite literally a very lightweight container of some unknown, but known to be uniquely identifying for some type, static const char * string. I think its class type and its list of member functions ought to be deliberately compile-time incompatible with std::type_info to force authors to upgrade their code. A conversion member function ought to be able to synthesise a corresponding std::type_info using typeid() from some boost::type_index&lt;T&gt;, but that&rsquo;s about it. I would even, personally speaking, go so far as to only provide a boost::type_index and no corresponding boost::type_info, especially if the boost::type_id&lt;T&gt;() function can return a const boost::type_index&lt;T&gt;&amp; and therefore can be used as a static const lref, or copy constructed from it etc.<p></p></p>
<p class="MsoListParagraphCxSpMiddle"><p>&nbsp;</p></p>
<p class="MsoListParagraphCxSpMiddle">A suggested name() member function replacement which correctly breaks out the multiple confounding uses of std::type_info::name() into each of their three use cases (and which intentionally causes any use of name() to fail to compile) might be:<p></p></p>
<p class="MsoListParagraphCxSpMiddle"><p></p></p>
<p class="MsoListParagraphCxSpMiddle">Bear in mind that user code can always subclass boost::type_index and add their own name() implementation based on one or more of the above new member functions.<p></p></p>
<p class="MsoListParagraphCxSpMiddle"><p>&nbsp;</p></p>
<p class="MsoListParagraphCxSpMiddle"><span><span>&middot;<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span>In other words, here I think &ldquo;less is more&rdquo; in every way you look at it. I think a slimmer less heavy TypeIndex would be a superior solution.<p></p></p>
<p class="MsoListParagraphCxSpMiddle"><p>&nbsp;</p></p>
<p class="MsoListParagraphCxSpLast"><span><span>&middot;<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span>I request the Review Wizards to allow Antony some time to make the changes to produce a v3 of the library, and then to allow TypeIndex v3 a Fast Track Review of five days to ensure the Boost community is happy and that its feedback has been incorporated. It was asked during peer review that such a five day period please include a weekend. I would be happy to serve as review manager again if requested.<p></p></p>
<p class="MsoNormal">Niall Douglas<br>Waterloo, Canada, November 2013<p></p></p>
<p class="MsoPlainText"><p>&nbsp;</p></p>
</div></div>
Niall Douglas | 12 Nov 20:34 2013

[boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov

Boost community feedback is requested for the formal peer review of 
the TypeIndex library by Antony Polukhin. Feedback requested 
includes:

1. Should this library be accepted into Boost?

2. Any conditions which should be attached to acceptance into Boost 
e.g. fixes, additional testing, changes to documentation. Please be 
as specific as possible here (bullet points are good!)

Peer review ends on Thursday 21st Nov, ten days from today. Based on 
your feedback, at that point I will decide if I recommend TypeIndex 
for inclusion in my report to the review wizards. Comments can be 
posted to boost <at> lists.boost.org if you expect others to comment on 
your post, or to me privately if you wish your comment to not be made 
public.

What is Boost.TypeIndex?

TypeIndex performs three main functions:

1. It provides a consistent, well defined, portable boost::typeid() 
implementation with a consistent, well defined, portable 
boost::type_info class implementation which mirrors std::type_info. 
Implementation-specific weirdnesses (e.g. std::type_info::raw_name(), 
the fact the hash_code is often terrible and collides frequently) are 
abstracted out into a single, portable API.

2. It provides the ability to convert a type into a uniquely 
identifiable, container indexable, boost::type_info instance (e.g. 
&typeid(T) or C++11 class std::type_index) with RTTI disabled, 
thereby removing the need for requiring RTTI enabled for many 
type_info use cases. Any features which require RTTI are very clearly 
denominated in the API's name.

3. It allows the following Boost libraries to eliminate their 
dependency on RTTI which is a big win for embedded systems use, and 
it supplies patches for these libraries replacing RTTI std::type_info 
with boost::type_info. Feedback from the maintainers and users of 
these Boost libraries is *particularly* welcomed:

Any, Graph, Property Map, Property Tree, Test, Variant, Xpressive

I believe that TypeIndex meets the Boost library requirements at 
http://www.boost.org/development/requirements.html, and I have 
personally verified that it builds and passes all unit tests on GCC 
4.6, clang 3.0 and MSVCs 10-12 [1]. I should add that Antony has 
already done three rounds of changes according to my feedback, and my 
thanks to him for being so dilligent and responsive.

NOTE: Please read the TypeIndex documentation (linked to below) 
before asking any questions e.g. about potential code bloat etc. 
You'll probably find the answer already there.

Source code: https://github.com/apolukhin/type_index/zipball/master

Github: https://github.com/apolukhin/type_index

Documentation: http://apolukhin.github.com/type_index/index.html

Any questions about topics not in the documentation? Please do ask.

[1]: A single unit test currently always is reported as failing to 
link correctly on MSVC. Antony believes this to be a bug in Windows 
bjam, as the Jamfile marks the link as expected to fail using 
link-fail but bjam does not respect this on Windows in this one use 
case scenario (yet weirdly the other expected link failures work 
fine!).

Niall

--

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

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

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

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

Gmane