Document number: N4038

Date: 2014-05-23

Proposal for Unbounded-Precision Integer Types

by Pete Becker

What’s New in this Revision

• In integer, replaced constructors taking arithmetic types with a templated constructor and added a templated assignment operator for arithmetic types. In bits, replaced constructors taking integral types with a templated constructor and added a templated assignment operator for integral types.
• Added integer::is_zero.
• Added noexcept to unary integer::operator- and unary integer::operator+.
• Added several issues raised by Marc Glisse.

Overview

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

Document number: N4033

Date: 2014-05-23

synchronized_value for associating a mutex with a value

by Anthony Williams

A couple of years ago I wrote an article for Dr Dobb's Journal discussing a synchronized_value template to associate a mutex with a value. I'd like to propose that template for standardization, with a few modifications.

The basic idea is that synchronized_value<T> stores a value of type T and a mutex. It then exposes a pointer interface, such that derefencing the pointer yields a special wrapper type that holds a lock on the mutex, and that can be implicitly converted to T for reading, and which forwards any values assigned to the assignment operator of the underlying T for writing. There is also an arrow operator which allows member functions on the wrapped value to be called...

Document number: N4032

Date: 2014-05-23

Comments on continuations and executors

by Anthony Williams

Having implemented the concurrency extensions from D3904 from the Issaquah wiki, it is apparent that there are several aspects of the specification which are incomplete, and others which I find undesirable.

This paper attempts to enumerate those aspects, and proposes fixes and suggestions.

Document number: N4026

Date: 2014-05-23

Nested namespace definition

by Robert Kawulak

The paper proposes allowing the use of a qualified name in a namespace definition to define several nested namespaces at once, for example:

    namespace A::B::C {
        //...
    }

The code above would be equivalent to:

    namespace A {
        namespace B {
            namespace C {
                //...
            }
        }
    }   

The feature was already proposed by Jon Jagger in 2003 in the paper N1524 Nested Namespace Definition Proposal, but it has been listed in N2869 State of C++ Evolution (Post San Francisco 2008) under “Not ready for C++0x, but open to resubmit in future”.

Document number: N4017

Date: 2014-05-22

Non-member size() and more

by Riccardo Marcangelo

This is a proposal to add non-member std::size and other useful utility functions (std::empty, std::front, std::back, and std::data). The inclusion of these functions would provide benefits in regards to safety, efficiency, and generality.

Document number: N3971

Date: 2014-05-22

Concurrency TS Editor's Report, May 2014

by Artur Laksberg

N3970 is the Concurrency TS Draft. It is based on D3904 with the following changes as per LEWG feedback: ...

Document number: N3970

Date: 2014-05-22

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

by Artur Laksberg

1This technical specification describes a number of concurrency extensions to the C++ Standard Library (1.2). These extensions are classes and functions that are likely to be used widely within a program and/or on the interface boundaries between libraries written by different organizations.

Document number: N4001

Date: 2014-05-23

SG5: Transactional Memory (TM) Meeting Minutes 2014/02/03-2014/05/19

by Michael Wong

Minutes for 2014/02/03 SG5 Conference Call ............................................................................... 2

Minutes for 2014/02/17 SG5 Conference Call ............................................................................... 6

Minutes for 2014/03/10 SG5 Conference Call ............................................................................... 9

Minutes for 2014/03/31 SG5 Conference Call ............................................................................. 13

Minutes for 2014/04/28 SG5 Conference Call ............................................................................. 18

Minutes for 2014/05/12 SG5 Conference Call ............................................................................. 21

Minutes for 2014/05/19 SG5 Conference Call ............................................................................. 27

Document number: N3999

Date: 2014-05-23

Standard Wording for Transactional Memory Support for C++

by Victor Luchangco, Jens Maurer, Michael Wong, et al.

1 Introduction

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.

This proposal is based in part on the Draft Specification for Transactional Constructs in C++ (Version 1.1) published by the Transactional Memory Specification Drafting Group in February 2012. It represents a pragmatic basic set of features, and omits or simplifies a number of controversial or complicated features from the Draft Specification. Our goal has been to focus SG5’s efforts towards a basic set of features that is useful and can support progress towards possible inclusion in the C++ standard.

In addition to a description of the proposal, this document contains a summary of the issues discussed Section 1.1 as well as Standard Wording for Core Section 8. Library wording is handled in a separate document.

1.1 Changes in previous revisions

N3999 (this paper): From N3919, we updated with discussion results from EWG, and the TM Evening Session of Issaquah. We considered the memory model effect from Chandler on whether a transaction that does not access any shared data induces any happens-before arcs – and in particular whether transactions that are provably thread-local must incur synchronization costs. We describe the result of that discussion in Section 7.1.

We also added Core StandardWording to support TM TS in preparation for the Draft Document. Core Standard Wording will be reviewed in a separate telecon call on June 2, and likely again at Rapperswil. Library wording is posted in N4000 and will be reviewed in Rapperswil.

Document number: N3988

Date: 2014-05-23

Towards restrict-like aliasing semantics for C++

by Hal Finkel, Hubert Tong, Chandler Carruth, Clark Nelson, Daveed Vandevoode, Michael Wong

This paper is a follow-on to N3635 after a design discussion with many compiler implementers at Issaquah, and afterwards by telecon, and specifically proposes a new alias_set attribute as a way to partition type-based aliasing to enable more fine grain control, effectively giving C++ a more complete restrict-like aliasing syntax and semantics.