C++11/14 compiler and library shootout

by C++ Rocks

It’s been almost a year since my last comparison of C++11 support across different compilers, so I decided to take a break from working on my book about C++11/14 features in VS2013, and see how things have changed.

Document number: N3966

Date: 2014-03-01

Fixes for optional objects

by Fernando Cacciola, Andrzej Krzemieński

This document proposes a number of wording fixes, as suggested in Issaquah meeting, to optional objects proposed in N3793. We do not propose any changes in the functionality. We only reworded the standardese, and applied bug fixes: ...

Document number: N3965

Date: 2014-02-28

Proposal for Unbounded-Precision Integer Types

by Pete Becker

Programmers sometimes need to manipulate integer values that are too large to repesent with C++’s standard integer types. Doing a Google search for terms that describe large integers produces many hits for libraries that handle large integers. These libraries vary in quality, from hacks by beginners to sophisticated, professional implementations. Also, Java has unbounded precision integers as part of its standard class library.

One important use for unbounded-precision integers is cryptography. Cryptographic applications typically manipulate integer values of several hundred digits. If the C++ standard library provides facilities for such values it will make cryptographic applications easier to write and to port.

There have been two Committee papers proposing unbounded-precision integer libraries for C++: N1718 (2004) and N2143 (2007), both by M.J. Kronenburg. Nothing was done with these papers, in part because there was too much else going on in the Library Working Group at the time. Now that the Committee is looking to greatly expand the scope of the standard library, it’s time to reconsider unbounded-precision integers.

Document number: N3964

Date: 2014-03-02

Library Foundations for Asynchronous Operations, Revision 1

by Christopher Kohlhoff

This document supersedes N3896. The term completion token is introduced to more clearly distinguish the purposes of the handler_type and async_result type traits, and a new template alias handler_type_t and template class async_completion are added. Code examples now use C++14 language facilities. Draft proposed wording is added in section 13, and a complete sample implementation is included in section 14.

Document number: N3963

Date: 2014-03-02

Centralized Defensive-Programming Support for Narrow Contracts (Revision 4)

by John Lakos, Alexei Zakharov

This proposal is a revision to N3877.

The standardese has been extensively redrafted based on feedback from the LWG at Issaquah.

Document number: N3962

Date: 2014-03-01

File System TS Editor's Report, February 2014 - Post-Issaquah

by Beman Dawes

N3940 is the latest File System TS Working Draft. It contains the changes to the File System PDTS as directed by the committee at the Issaquah meeting. Details of the changes are listed below.

Document number: N3960

Date: 2014-02-28

Working Draft, Technical Specification for C++ Extensions for Parallelism

by Jared Hoberock

The goal of this Technical Specification is to build widespread existing practice for parallelism in the C++ standard algorithms library. It gives advice on extensions to those vendors who wish to provide them.

Document number: N3951

Date: 2014-02-07

C++ type reflection via variadic template expansion

by Cleiton Santoia Silva and Daniel Auresco

From a type T, gather member name and member type information, via variadic template expansion.

Document number: N3950

Date: 2014-02-19

Defaulted comparison operators

by Oleg Smolsky

Provide means of generating default equality, inequality and comparison member operators for user-defined types. This is strictly an "opt in" feature so that semantics of existing code remain intact.

Document number: N3948

Date: 2014-02-20

Feature-testing for C++ Technical Specifications

by Clark Nelson

Introduction

One of the primary reasons for defining the feature-test macros for C++14 in a document separate from the standard was to avoid even the impression that standard features are optional. Because features described in a Technical Specification are by definition optional, it is not clear that there is good justification for putting feature-testing facilities for a TS in a different document.

It was important for someone to “back-fill” feature-testing facilities for the new features of C++14, so SG10 undertook that task. But going forward, it would probably be better for feature-testing to be considered as part of the design of a new feature, and a descriptive and unique macro name selected, when necessary, by those who understand it best.

In addition, it is not clear that SG10 has yet adequately considered what to do about issues like ABI compatibility and versioning of interfaces for a library. It may well be that it would be more efficient for such discussions to happen in a library WG.

For all these reasons, it seems that discussion of feature-testing should not be happening exclusively within SG10.

The remainder of this document consists mainly of tables such as were used to drive discussions within SG10, to serve as starting points for discussions in other groups...