Document number: N3975

Date: 2014-05-22

URI - Proposed Wording (Revision 5)

by Glyn Matthews and Dean Michael Berris

Revisions to N3947

1. Numerous updates to wording and style to make it more compatible with the standard document.
2. Removed string_type member typedef for the uri class.
3. Improved specification of the definition of port [uri.definition.port].
4. Updated [uri.requirements] to be the same as the filesystem proposal.
5. Renamed uri_error_code to uri_errc [class.uri_errc].
6. Added an additional sentence in [uri.scope] to describe the uri_errc enum.
7. Made member functions constexpr and noexcept, where appropriate.
8. Improved specification of equality and comparison operators [uri.header-synopsis.equality-comparison].
9. Added a section describing uri encoding conversions [class.uri.conversions]
10. Added some sentences on make_error_code, make_error_condition and uri_category [uri.header-synopsis.error-handling].
11. Updated uri_builder.
12. Improved specification for to_uri and to_filesystem_path to handle the case where the URI or filesystem path is relative [uri.header-synopsis.filesystem-interop].

Document number: N4015

Date: 2014-05-20

A proposal to add a utility class to represent expected monad

by Vicente J. Botet Escriba and Pierre Talbot

Class template expected<E,T> proposed here is a type that may contain a value of type T or a value of type E in its storage space. T represents the expected value, E represents the reason explaining why it doesn't contains a value of type T, that is the unexpected value. Its interface allows to query if the underlying value is either the expected value (of type T) or an unexpected value (of type E). The original idea comes from Andrei Alexandrescu C++ and Beyond 2012: Systematic Error Handling in C++ talk. The interface and the rational are based on std::optional N3793 and Haskell monads. We can consider that expected<E,T> is a generalization of optional<T> providing in addition a monad interface and some specific functions associated to the unexpected type E. It requires no changes to core language, and breaks no existing code.

Document number: N3989

Date: 2014-05-23

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

by Jared Hoberock

This Technical Specification describes requirements for implementations of an interface that computer programs written in the C++ programming language may use to invoke algorithms with parallel execution. The algorithms described by this Technical Specification are realizable across a broad class of computer architectures. ... The goal of this Technical Specification is to build widespread existing practice for parallelism in the C++ standard algorithms library.

Document number: N4000

Date: 2014-05-23

Standard wording for a Transaction-safe C++ Standard Library std::list

by Michael Wong, et al.

This paper documents our effort to transactionalize a C++ Standard Template Library (STL) container to demonstrate the feasibility of the transactional language constructs proposed by Study Group 5 (SG5): Transactional Memory. We began this study with std::list and made it transaction-safe using the transactional memory support in GCC 4.9. ...

Changes from previous versions

N4000 (this paper): present updates and summary from LEWG and propose wording for TM TS for LWG

Document number: N3990

Date: 2014-05-08

Adding standard circular shift operators for computer integers

by Daniel Gutson, Angel Bustamente

C and C++ languages have the standard set of bitwise operations, including OR, AND, XOR, LEFT/RIGHT SHIFT, NOT. However, circular shift (left and right rotate) isn't included in the language.

Document number: N3987

Date: 2014-05-07

Yet another set of C++ type traits

by Cleiton Santoia Silva and Daniel Auresco

Just as exercise you can pick all keywords of C++ and put a is_ before and thought if it make sense.

Document number: N3986

Date: 2014-04-25

Adding Standard support to avoid padding within structures

by Sebastian Davalle, Daniel Gutson, Angel Bustamante

Sometimes programmers might need to avoid the bitfields’ alignment to get a compact type. Although this behavior can be obtained in most compilers by specifying the "packed" attribute, a more standard and simpler way to force it should exist (similar to the :0 syntax).

Document number: N3985

Date: 2014-05-06

A proposal to add coroutines to the C++ standard library (Revision 1)

by Oliver Kowalke and Nat Goodspeed

Changes in this revision

This document supersedes N3708. A new kind of coroutines -- std::symmetric_coroutine<T>
-- is introduced and additional examples (like recursive SAX parsing) are added.

A section explains the benfits of using coroutines in the context of event-based asynchronous model.

Document number: N3984

Date: 2014-05-07

Adding attribute reflection to C++

by Cleiton Santoia Silva and Daniel Auresco

C++ reflection mechanism could benefit from a more complete set of functionality, if we define how to
reflect attributes as well as types.

Document number: N3983

Date: 2014-05-07

Hashing tuple-like types

by Geoffrey Romer

This paper proposes to add std::hash specializations for the “tuplelike” types in the standard library, namely std::pair, std::tuple, and std::array.