Document number: N3870

Date: 2014-01-14

Extending make_shared to Support Arrays, Revision 1

by Peter Dimov, Glen Fernandes

This paper proposes adding array support to make_shared, via the syntax make_shared<T[]> and make_shared<T[N]>.

Changes in Revision 1: This revision of N3641 significantly narrows the scope of the proposal, based on feedback from Jeffrey Yasskin and Stephan T. Lavavej. It cuts down the number of make_shared overloads considerably, leaving only two use cases:

— Value initialization, analogous to new U[N]():

template<class T> shared_ptr<T> make_shared(size_t N); // T is U[]
template<class T> shared_ptr<T> make_shared(); // T is U[N]

— Per-element initialization to a specified value, analogous to the std::vector<U>(N, u) constructor:

template<class T> shared_ptr<T> make_shared(size_t N, const U& u); // T is U[]
template<class T> shared_ptr<T> make_shared(const U& u); // T is U[N]

Document number: N3869

Date: 2014-01-12

Extending shared_ptr to Support Arrays, Revision 1

by Peter Dimov

This paper proposes adding array support to shared_ptr, via the syntax shared_ptr<T[]> and shared_ptr<T[N]>.

Changes in Revision 1: Incorporated wording suggestions from Daniel Krügler.

Document number: N3867

Date: 2014-01-19

Specializations and namespaces (Rev. 2)

by Mike Spertus

We propose to allow specializing templates from within a different namespace. The motivation is that when we declare a new class, it is natural to want to provide associated template specializations. For example, it is really painful that whenever I declare a class, I need to class all open namespaces and enter namespace std just to specialize std::hash as shown below ...

The technical point is that the primary template identifies the template's namespace, so we don't need to use the namespace enclosing the specialization's definition to identify it's namespace.

Document number: N3866

Date: 2014-01-19

Invocation type traits (Rev. 2)

by Mike Spertus

We propose a (compiler-supported) type trait std::invocation_type whose type typedef is the implied function type of the callable object when called with the given argument types.

For example, if we define C as

struct C {
  int operator()(double d, int i);
  int operator()(double d1, double d2);
};

then std::invocation_type<C(int, int)>::type would be int(double, int). More precisely the return type of invocation_type<Fn(ArgTypes...)> is result_of<Fn(ArgTypes...)> and each argument type is the same as the formal parameter type matched in the call to Fn. For more detailed information, see the use cases and wording below.

The main difference between this and previous revisions is that we add two variants of the invocation_type.

Document number: N3865

Date: 2014-01-18

More Improvements to std::future

by Vicente J. Botet Escriba

This proposal is an evolution of the functionality of std::future/std::shared_future that complements the proposal "N3784 Improvements to std::future<T> and Related APIs" [3] with more future observers and factories mainly based on the split between futures having a value or a exception.

Document number: N3864

Date: 2014-01-08

A constexpr bitwise operations library for C++

by Matthew Fioravante

This proposal adds support for low level bitwise and logical operations to C++.

Document number: N3863

Date: 2013-12-08

Private Extension Methods

by Matthew Fioravante

This proposal adds a new mechanism for declaring non-virtual private class methods and static private class methods outside of the class definition.

Document number: N3862

Date: 2014-01-20

Towards a Transaction-safe C++ Standard Library: std::list

by Justin Gottschlich, Michael Spear, 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. The changes were minimal and were generally restricted to the addition of transaction_safe keyword to a few interfaces such as allocate, deallocate, and swap functions. The rest of the changes were added to internal helper functions. Some of the issues that we considered were the constant time complexity of std::list.size() and friends, and its const noexcept nature. This experience shows that the safety of STL containers must not be specified directly, but instead should be inherited from the type with which the container is instantiated. For our future work, we plan to expand this effort to other STL containers as well as converting the clang/llvm C++ library.

Document number: N3861

Date: 2014-01-20

SG5: Transactional Memory (TM) Meeting Minutes 2013/09/09-2014/01/20

by Michael Wong

Minutes for 2013/09/09 SG5 Conference Call ............................................................................... 2
Minutes for 2013/10/14 SG5 Conference Call ............................................................................... 6
Minutes for 2013/10/28 SG5 Conference Call ............................................................................. 11
Minutes for 2013/11/11 SG5 Conference Call ............................................................................. 15
Minutes for 2013/11/25 SG5 Conference Call ............................................................................. 19
Minutes for 2013/12/09 SG5 Conference Call ............................................................................. 22
Minutes for 2014/01/06 SG5 Conference Call ............................................................................. 27
Minutes for 2014/01/13 SG5 Conference Call ............................................................................. 31

Document number: N3859

Date: 2014-01-20

Transactional Memory Support for C++

by Victor Luchango et al.

Transactional memory supports a programming style that is intended to facilitate parallel execution with a comparatively gentle learning curve. This document describes a proposal developed by SG5 to introduce transactional constructs into C++ as a Technical Specification. It is a revision of N3718, an earlier document with the same title, presented at the September 2013 meeting in Chicago. However, this document is self-contained, and can be read independently of N3718. At the Chicago meeting, we received encouraging and helpful feedback, which we have used to revise this proposal.