Document number: N4229

Date: 2014-10-13

Pointer ordering

by Gabriel Dos Reis

This paper suggests a simple fix to an embarrassing glaring hole in the standard library section regarding pointer comparison function objects: that they yield the same result as the built-in comparison operators when the result is defined for the latter.

Document number: N4210

Date: 2014-10-10

IBM comment on preparing for a Trigraph-adverse future in C++17

by Michael Wong, Hubert Tong, Rajan Bhakta, Derek Inglis

In Rapperswil, EWG had a vote to remove Trigraph based on N3981...

IBM was asked by Bjarne to look at how many real users of EBCDIC that use trigraphs there remain and to return to EWG with a position. This paper summarizes that IBM position, give guidance for trigraph users moving forward, and outline IBM future voting plan on this issue. As such, we will tell the story of the Bad, the Good, and the Ugly.

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.