Document number: N4182

Date: 2014-10-10

SG5 Transactional Memory Meeting Minutes 2014/07/14-2014/10/06

by Michael Wong

Minutes for 2014/07/14 SG5 Conference Call

Minutes for 2014/07/28 SG5 Conference Call

Minutes for 2014/08/11 SG5 Conference Call

Minutes for 2014/08/25 SG5 Conference Call

Minutes for 2014/09/08 SG5 Conference Call

Minutes for 2014/09/22 SG5 Conference Call

Minutes for 2014/10/06 SG5 Conference Call

Document number: N4180

Date: 2014-10-10

SG5 Transactional Memory Support for C++ Update

by Michael Wong et al.

This paper (N4180) is an update of the Transactional Memory design proposal outlined in N3999 based on feedbacks from Rapperswil Core and Library working group Review. A separate paper (N4179) describes the wording changes that support all the following changes.

Specifically, it describes these changes to N3999’s design...

Document number: N4128

Date: 2014-10-10

Ranges for the Standard Library, Revision 1

by Eric Niebler

This paper outlines what support for ranges in the C++ standard library might look like. Rather than presenting a final design, this paper proposes a set of concepts and guidelines for using them to implement range-based versions of the standard algorithms. It draws inspiration from the Boost.Range[4] library, the range algorithms in Adobe Source Libraries[1], Elements of Programming by Stepanov and McJones (2009) [20], and from N3351 “A Concept Design for the STL” by Stroustrup and Sutton (2012) [21]. In addition to presenting the concepts and guidelines, this paper discusses the rationale behind each, weighing different design options.

The decision to defer any discussion about specific wording was taken in recognition of the fact that any range design is likely to undergo significant revision by the committee. The paper is intended merely as a starting point for discussion and as a basis for future work.

This paper assumes the availability of Concepts Lite; however, everything suggested here has been implemented in C++11, where Concepts Lite has been simulated with the help of generalized SFINAE for expressions.

Document number: N4165

Date: 2014-10-04

Unified Call Syntax

by Herb Sutter

Like [1], this paper proposes generalizing the member call syntax x.f(a,b) or x->f(a,b) to allow calling nonmembers.

Document number: N4176

Date: 2014-10-11

Thoughts about comparisons

by Bjarne Stroustrup

This is a summary of some of the discussion of my Default Comparisons draft. It lists the various proposals and compares them according to a set of criteria. I would be particularly interested in comments about the choice of comparison criteria (pun intended).

Document number: N4175

Date: 2014-10-11

Default comparisons

by Bjarne Stroustrup

Defining comparison operators (==, !=, <, <=, >, and >=) for simple classes is tedious, repetitive, slightly error-prone, and easily automated. I propose to (implicitly) supply default versions of these operations, if needed. The semantics of = is equality of every member. The meaning of < is a lexicographical order of elements. If the simple defaults are unsuitable for a class, a programmer can, as ever, define more suitable ones or suppress the defaults.

Document number: N4174

Date: 2014-10-11

Call syntax: x.f(y) vs. f(x,y)

by Bjarne Stroustrup

This note explores the possibility of providing a uniform call syntax by giving member functions preference over non-member functions. Offering the choice between the x.f(y) and f(x,y) notations with different meanings means that different people will chose differently for their function definitions, so that users have to know the choice and write calls appropriately. This gives users more opportunities for making mistakes, makes it harder to write generic code, and has led to replication when people define both a member and a non-member function to express the same thing. I suggest that providing different meanings to the two syntaxes offers no significant advantage.

Document number: N4173

Date: 2014-10-11

Operator Dot

by Bjarne Stroustrup and Gabriel Dos Reis

This is a proposal to allow user-defined operator dot (operator.()) so that we can provide “smart references” similar to the way we provide “smart pointers.” The gist of the proposal is that if an operator.() is defined for a class Ref then by default every operation on a Ref object is forwarded to the result of operator.(). However, an operation explicitly declared as a member of Ref is applied to the Ref object without forwarding. A programmer can prevent a pointer to a referred-to object from “leaking” into the larger program by declaring operator.() private.

Document number: N4221

Date: 2014-10-10

Generalized lifetime extension

by David Krauss

Document number: N4220

Date: 2014-10-10

An update to the preprocessor specification (rev. 2)

by David Krauss

This proposal updates the preprocessor specification to remove undefined behavior, missing specifications, and possible contradictions, and to better document implementation differences. It resolves CWG DR 268, 366, 897, 1436, 1625, 1698, 1709, 1718, and 1882. Issues related to universal-character-names are not addressed here, but in N4219.