N4580: WG21 2016-02-19 Telecon Minutes -- Jonathan Wakely

By Blog Staff | Feb 23, 2016 09:41 AM | Tags: None

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4580

Date: 2016-02-19

WG21 2016-02-19 Telecon Minutes

by Jonathan Wakely

New Options for Managing Character Sets in the Microsoft C/C++ Compiler--Jim Springfield

By Marco Arena | Feb 23, 2016 01:47 AM | Tags: None

A new post from the Visual C++ team about how VC++ has evolved in the past for supporting different characters sets, and what's new:

New Options for Managing Character Sets in the Microsoft C/C++ Compiler

by Jim Springfield

From the article:

The Microsoft C/C++ compiler has evolved along with DOS, 16-bit Windows, and 32/64-bit Windows.  Its support for different characters sets, code pages, and Unicode has also changed during this time...

N4578-79: Parallelism TS2 proposed working draft

By Blog Staff | Feb 22, 2016 04:13 PM | Tags: None

New WG21 papers are available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

N4578: Working Draft, Technical Specification for C++ Extensions for Parallelism Version 2 (Jared Hoberock)

N4579: Parallelism TS Editor’s Report (Jared Hoberock)

N4578 is the proposed working draft of Parallelism TS Version 2. It contains technical changes to the Parallelism TS to apply the following revision:

• P0155R0 - Task Block R5

N4578 updates the previous draft, N4505, published in the post-Lenexa mailing.

Technical Changes

• Applied P0155R0, which introduces support for fork-join task parallelism

via task blocks.

A bit of background for the operator dot proposal -- Bjarne Stroustrup

By Bjarne Stroustrup | Feb 22, 2016 03:27 PM | Tags: None

Over the years, there have been several suggestions and proposals for allowing programmers to define operator.() so as  to be able to provide “smart references” similar to the way we provide “smart pointers.” I first considered that in 1983, but couldn’t solve the problem. In early 2014, Gabriel Dos Reis and I decided that now we really had to solve it: Too much code was getting too complicated and too ugly because of the lack of smart references. Operator -> is good for objects with pointer semantics, but we needed a general way of providing value semantics for a handle.

Operator dot differs from other operators by having its right-hand operand be a name rather than a value: for x.m, m is not the value of some variable it is the name of a member of some class. Ideally, dot would be a binary operator taking into account both x and m for x.m. Many have tried, including Gaby and I, but that quickly gets complicated. The current rules for operator->() and the proposed design for operator.() “solves” those problems by considering the right-hand operand only when looking for possible candidates. This allows composition of interfaces without requiring inheritance. If someone figures out a good and simple way of taking the member name into account in a more general form, we are reasonably sure that we have not proposed anything that prevents that. When designing, you must always try to avoid painting yourself into a corner by closing off possible evolution paths.

Historically, the key sticking point with the operator.() proposals has been how to distinguish operations on the reference object (the handle) from operations on the referred-to object (the value). The current proposal “forwards” every operation to the referred-to object unless that operation has been explicitly declared in the handle. This is simple and quite general. In particular, we can apply operators on a smart reference (e.g., ++r) and have ++ apply to reference is we so desire, but by default it is applied to the referred-to object (as it would for a built-in reference). The papers outline why we think that this is – by far – the design that best balances the needs of the various use cases. The focus is on allowing the user to define a class that is a reference, just like the built-in reference, except that it is “smart” in some way (e.g., it can have a rebind() member) analogously to the way a “smart pointer”  is just like a pointer except that it is “smart” in some way (e.g., takes care of ownership). If you can define or use a smart pointer, you can define or use a smart reference.

The proposal has been quite stable. There have been proposals for alternatives and major extensions, but few suggested modifications. We tried to find a way to prevent a pointer (or reference) to the referred-to object to escape from the smart reference, but couldn’t find a simple way of guaranteeing that so we gave up, quoting “C++ protects against Murphy, not Machiavelli.” We ensured that you can define a matching set of smart . (dot), -> (arrow), * (dereference), and [] (subscript) operators with the relations they have for built-in types.

• James Adcock: Request for Consideration – Overloadable Unary operator.().
• Koenig and B. Stroustrup: Analysis of Overloaded operator.().
• G. Powell, D. Gregor, and J. Jarvi: Overloading Operator.() & Operator.*().
• B. Stroustrup: The Design and Evolution of C++. Addison-Wesley, 1994.
• B. Stroustrup and G. Dos Reis:  Operator Dot (R2).
• Bjarne Stroustrup and Gabriel Dos Reis: Operator Dot Wording.

2016-02 Pre-Jacksonville mailing available

By Blog Staff | Feb 18, 2016 09:46 AM | Tags: None

The 2016-02 mailing of new standards papers is now available.

NOTE: A number of these papers have already been publicized on this blog. This is the complete list including ones not previously publicized.

A bit of background for the unified call proposal

By Bjarne Stroustrup | Feb 14, 2016 03:43 PM | Tags: None

C++ provides two calling syntaxes, x.f(y) and f(x,y). This has bothered me for a long time. I discussed the problem in the context of multimethods in D&E in 1994, referring back to a proposal by Doug Lea from 1991, and again in 2007. Each of the syntaxes has its virtues, but they force design decisions on people, especially library designers. When you write a library, which syntax do you use for operations on objects passed to you by your users? The STL insists on the traditional functional syntax, f(x,y), whereas many OO libraries insist on the dot notation, x.f(y). In turn, libraries force these decisions on their users.

Interestingly, I solved the problems for operators: x+y doesn’t care whether you provide operator+(T,T) or T::operator+(T). The problem is getting more noticeable as we get more generic libraries. Note begin(c) and c.begin() for range-for loops and in general code. Why do we/someone have to write both? If c.begin() exists, begin(c) should find it, just as x+y finds the right implementation. Such call-syntax adapters are pure overhead and different people’s adapters can clash.

In early 2014, Herb Sutter and I each independently decided to propose a unified syntax. Herb suggested unification based on allowing x.f(y) to find a non-member function, giving preference to the x.f(y) syntax, whereas my ideal was that x.f(y) and f(x,y) should mean exactly the same. After a quick discussion, we joined forces. Based on real input from code and users, I reluctantly agreed that for compatibility reasons, x.f(y) and f(x,y) could not mean exactly the same. The only feasible way forward was to do a traditional lookup based on the syntax used, and then try the other syntax if the first one failed. Stability – backwards compatibility – is an important feature, overruling my desire for perfection.

To my surprise, many people came out strongly against x.f(y) finding f(x,y) – even if member functions were preferred over free-standing functions by the lookup rules. I received email accusing me of “selling out to the OO crowd” and people whose experience and opinion I respect insisted that x.f(y) finding f(x,y) would seriously compromise their ability to design stable interfaces. I think those fears are greatly exaggerated, but I could be wrong. Also, I prefer the dot syntax in some cases; for example, I find x.f(y).g(z) more readable than g(f(x,y),z). However, there was no chance of acceptance of a proposal that included x.f(y) finding f(x,y). Maybe modules will eventually help here. Furthermore, David Vandevoorde pointed out that because of the two-phase lookup rules having x.f(y) find f(x,y) would complicate the task for compiler writers and possibly be expensive in compile time.

So, we are left with a simple proposal to allow f(x,y) to find x.f(y) where f(x,y) wouldn’t work today. This solves the problem for library writers and their users along the lines of the STL:

• Library designers don’t have to force users to use one preferred syntax or to duplicate the implementation to handle both.
• It allows us to write simple concepts for new libraries.
• We no longer have to write call-syntax adapters.
• We can in many cases add functionality to an abstraction without modifying a class
• We no longer have to bother the users with the distinction between member functions and helper functions.

The proposal was approved by the Evolution Working Group. Faisal Vali did an experimental implementation in Clang. Now we just have to hope that we can agree on exact wording in time for C++17. I consider it a small proposal that will significantly simplify the way we design and use libraries.

• Bjarne Stroustrup: The Design and Evolution of C++. Addison-Wesley, 1994.
• P. Pirkelbauer, Y. Solodkyy, and B. Stroustrup: Open Multi-Methods for C++. Proc. ACM GPCE’07.
• Herb Sutter: Unified Call Syntax.
• Bjarne Stroustrup: Call syntax: x.f(y) vs. f(x,y).
• Bjarne Stroustrup and Herb Sutter: Unified Call Syntax: x.f(y) and f(x,y).
• Bjarne Stroustrup: Unified Call Concerns.
• Bjarne Stroustrup and Herb Sutter: Unified Call Syntax Wording.

New papers: Iterator facade for ranges; adopt File System TS for C++17; unified call syntax wording

By Blog Staff | Feb 11, 2016 06:04 PM | Tags: None

Note: This is the last batch of individually- or small-group-posted papers this week. Tomorrow is the pre-Jacksonville paper mailing deadline, so we expect a bunch of papers to come in all at once, and instead of blogging about them individually, those will all advertised here next week as part of the mailing blog post.

New WG21 papers are available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

P0186R0: Iterator Facade Library Proposal for Ranges (Beman Dawes, Eric Niebler, Casey Carter)

Proposes a library component for easily creating conforming iterators. Based on existing practice. Depends only on the C++17 working paper plus Concepts TS and Ranges TS. Breaks no existing code or ABI's. Two open-source implementations including test suites available. Proposed wording provided.

P0218R0: Adopt the File System TS for C++17 (Beman Dawes)

Technical work on N4100, File System Technical Specification, ISO/IEC TS 18822:2015, was completed in July 2014, and published by ISO in July 2015. There are three shipping implementations and one soon-to-ship implementation. Two of the shipping implementations have been have been in use for several years. This document proposes adopting the File System Technical Specification, with corrections, for C++17. The alternative to this proposal is to start work on version two of the File System TS. Doing nothing is not an alternative.

P0251R0: Unified Call Syntax Wording (Bjarne Stroustrup, Herb Sutter)

This is the proposed wording for a unified call syntax based on the idea that f(x,y) can invoke a member function, x.f(y), if there are no f(x,y). The inverse transformation, from x.f(y) to f(x,y) is not proposed. [...] As agreed in EWG at the Kona meeting, the intent of the wording is: For f(x,y), see if f(x,y) is valid and if so do that call; otherwise try x.f(y).

A bit of background for the structures bindings proposal

By Bjarne Stroustrup | Feb 11, 2016 12:17 PM | Tags: None

[This note from Bjarne provides some background for the updated structured bindings proposal posted yesterday. --Ed.]

In the context of the C++ Core Guidelines, we (Herb Sutter, Gabriel Dos Reis, me, and few others) were discussing sources of bugs and inefficiencies. We noticed that returning multiple values (e.g., from a tuple) was one of the two remaining sources of uninitialized variables. We noticed that there were real cases of bugs and inefficiency (from default initialization followed by assignment rather than initialization) stemming from separating variable introduction from initialization. Use of tie() is at best a partial solution that doesn’t get to the root of the problem.

The next day or so, Herb had a first draft of a proposal. We refined it, adding use cases and implications. I noted that we had a syntax in concepts for the introduction of multiple names that we could borrow. We noted that whatever we came up with had to fit into our ideas for a possible future far-more-general pattern matching design. We always try to ensure that a proposal doesn’t block an important potential evolution path. The design document for the proposal was refined and extended.

It was now obvious that the proposal completed C++’s mechanism for returning multiple values from a function: With structured binding, we can initialize a set of values, {x,y,z},  just as we  can return a set of values, {e1,e2,e3}.

In web discussions, and especially at the Kona standards meeting, many alternatives were discussed. We focused on how to deal with user-defined types with private members. The new feature mustn’t discourage encapsulation by providing a convenient notation for structs only. We also considered whether explicit declaration of types were needed and how to achieve conversions. A conversion from a char[] in a return value to a string was considered particularly desirable by several people. These two needs were both addressed by adding the ability for users to define get<N> functions for a class. Jens Maurer refined the proposed wording and in doing so found a few weaknesses in the design.

For the details and code examples, you can find the current proposal and wording papers here for the upcoming meeting in Jacksonville.

P0144R1 and P0217R0: Structured bindings (Sutter, Stroustrup, Dos Reis) and wording (Maurer)

By Blog Staff | Feb 10, 2016 05:28 PM | Tags: None

New WG21 papers are available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

P0144R1: Structured bindings (Herb Sutter, Bjarne Stroustrup, Gabriel Dos Reis)

This paper proposes the ability to declare multiple variables initialized from a tuple or struct, along the lines of:

tuple f(/*...*/) { /*...*/ return {a,b,c}; } 

auto {x,y,z} = f(); // x has type T1, y has type T2, z has type T3 

This addresses the requests for support of returning multiple values, which has become a popular request lately.

Proposed wording appears in a separate paper, P0217.

P0217R0: Proposed wording for structured bindings (Jens Maurer)

This paper presents the proposed wording to implement structured bindings as described by Herb Sutter, Bjarne Stroustrup, and Gabriel dos Reis in P0144R1.

P0221R0: Proposed wording for default comparisons, revision 2 -- Jens Maurer

By Blog Staff | Feb 10, 2016 09:59 AM | Tags: None

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: P0221R0

Date: 2016-02-10

Proposed wording for default comparisons, revision 2

by Jens Maurer

Excerpt:

This paper presents design rationale and proposed wording to implement default comparisons for class types. It is a revision of N4532 with additional updates from the Evolution Working Group session at the Kona meeting of WG21 and in-depth discussions with interested parties. Blue text in the proposed wording indicates changes compared to N4532.

This paper assumes that the reader is familar with N4475 "Default comparisons (R2)" by Bjarne Stroustrup. In particular, default comparisons are assumed to be implicit (i.e. require no extra syntax to be available).