Document number: N3932

Date: 2014-02-14

Variable Templates For Type Traits (Revision 1)

by Stephan T. Lavavej

This updates N3854 [1] in response to the resolution for LWG 2112 [2], adding is_final_v...

Document number: N3927

Date: 2014-02-13

Definition of Lock-Free

by Lawrence Crowl

This paper addresses issue LWG 2075: Progress guarantees, lock-free property, and scheduling assumptions. This issue is also US 5 in N3733 ISO/IEC CD 14882, C++ 2014, National Body Comments.

Document number: N3925

Date: 2014-02-14

A sample Proposal, v4

by Walter Brown

This paper proposes to add to the standard library an interface for two algorithms carrying out random sampling. Such algorithms have long been part of the original (SGI) implementation of the Standard Template Library. ...

5 Acknowledgments

Many thanks to the readers of early drafts of this paper for their thoughtful comments, and to Matt Austern for the original proposal of the sampling algorithms.

Document number: N3924

Date: 2014-02-14

Discouraging rand() in C++14, v2

by Walter Brown

In their final Chicago deliberations re [N3775] vis-à-vis National Body comment US21, LEWG and LWG achieved joint consensus (1) to deprecate std::random_shuffle for C++14 as proposed, and (2) to strengthen the existing Note in [c.math]/5 in order to further encourage rand() users to migrate to the <random> component of the C++11 standard library. This paper provides wording to implement these decisions. ...

3 Acknowledgments

Many thanks, for their thoughtful comments, to Stephan T. Lavavej and the other reviewers of early drafts of this paper.

Document number: N3923

Date: 2014-02-14

A SFINAE-Friendly std::iterator_traits, v3

by Walter Brown

This paper provides wording to reformulate the specification of iterator_traits so as to avoid a hard error when its template argument does not have the member types expected of a nonpointer iterator, and thus to make the trait conveniently usable in a SFINAE context.

Document number: N3921

Date: 2014-02-14

string_view: a non-owning reference to a string, revision 7

by Jeffrey Yasskin

References to strings are very common in C++ programs, but often the callee doesn't care about the exact type of the object that owns the data...

Google, LLVM, and Bloomberg have independently implemented a string-reference type to encapsulate this kind of argument. ...

Acknowledgements

I'd like to thank Marshall Clow, Olaf van der Spek, the Boost and std-proposals mailing lists, Chandler Carruth, Beman Dawes, Alisdair Meredith, and especially Daniel Krügler for help, advice, and wording in this paper.

Document number: N3920

Date: 2014-02-13

Extending shared_ptr to Support Arrays, Revision 2

by Peter Dimov

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

...

Thanks to Glen Fernandes, whose contribution of boost::make_shared for arrays prompted the boost::shared_ptr additions proposed herein.

Thanks to Daniel Krügler for reviewing an earlier revision of this paper and suggesting wording improvements.

Thanks to Jonathan Wakely for providing valuable feedback.

Document number: N3916

Date: 2014-02-14

Polymorphic Memory Resources -- r2

by Pablo Halpern

A significant impediment to effective memory management in C++ has been the inability to use allocators in non-generic contexts. In large software systems, most of the application program consists of non-generic procedural or object-oriented code that is compiled once and linked many times. Allocators in C++, however, have historically relied solely on compile-time polymorphism, and therefore have not been suitable for use in vocabulary types, which are passed through interfaces between separately-compiled modules, because the allocator type necessarily affects the type of the object that uses it. This proposal builds upon the improvements made to allocators in C++11 and describes a set of facilities for runtime polymorphic memory resources that interoperate with the existing compile-time polymorphic allocators. In addition, this proposal improves the interface and allocation semantics of some library classes, such as std::function, that use type erasure for allocators.

...

11 Acknowledgements

I’d like to thank John Lakos for his careful review of my introductory text and for showing me what allocators can really do, if correctly conceived. Also, a big thank you to the members of my former team at Bloomberg for your help in defining the concepts in this paper and reviewing the result, especially Alexander Beels, Henry Mike Verschell, and Alisdair Merideth, who reworked the usage example for me. Thanks to Mark Boyall for promoting the addition of new allocators to the standard and for reviewing an early draft of this paper.

Document number: N3915

Date: 2014-02-14

apply() call a function with arguments from a tuple (V3)

by Peter Sommerlad

This is a slightly update from the wording of N3829 as proposed by LEWG in Issaquah, adding std:: again where necessary and constexpr.

N3658 and its predecessor N3493 introduced integer_sequence facility and provide application of this features, for example apply() that is proposed in this paper.

...

Acknowledgements go to Jonathan Wakely for providing integer_sequence and providing apply() as the example in the working draft. He also suggested a big improvement to the resulting standard change from N3802.

Acknowledgements go to Mike Spertus for making me aware of the ... pack formation approaches.

Acknowledgements to the following persons on the c++std-lib reflector for their feedback and encouragement: Jonathan Wakely, Andy Sawyer, Stephan T. Lavavej, Jared Hoberock, and Tony van Eerd.

Document number: N3910

Date: 2014-02-14

What can signal handlers do?

by Hans-J. Boehm

This is a revision of N3787. It attempts to reflect the remaining comments from CWG discussions in Chicago. It also reflects further in person discussions with Jens Maurer and Clark Nelson at the Issaquah meeting, and subsequent feedback from both SG1 and core. Some of the wording here came directly from Jens.

... in the process of relaxing the restrictions on asynchronous signal handlers to allow use of atomics, we inadvertently made it impossible to use even local variables of non-volatile, non-atomic type.