N4571: 2016-11 Issaquah meeting information -- Herb Sutter

By Blog Staff | Jan 22, 2016 08:47 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: N4571

Date: 2016-01-21

2016-11 Issaquah meeting information

by Herb Sutter

N4568: PL22.16/WG21 draft agenda: 29 Feb-05 Mar 2016, Jacksonville, FL/US -- Clark Nelson

By Blog Staff | Dec 9, 2015 10:59 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.

N4568.pdf

Document number: N4568

Date: 2015-12-08

PL22.16/WG21 draft agenda: 29 Feb-05 Mar 2016, Jacksonville, FL/US

by Clark Nelson

P0143R0: Wording for Modules -- Gabriel Dos Reis

By Blog Staff | Dec 2, 2015 02:30 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.

Document number: P0143R0

Date: 2015-11-30

Wording for Modules

by Gabriel Dos Reis

Excerpt:

This documents provides formal wording for a module system for C++. This document is to be read in conjunction with document P0142R0 “A Module System for C++”. The proposed wording are with respect to WG21 Committee Draft (N4567)

2015-11 post-Kona mailing available

By Blog Staff | Nov 18, 2015 10:03 AM | Tags: None

The 2015-11 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.

Trip Report: C++ Standards Meeting in Kona, October 2015--Botond Ballo

By Adrien Hamelin | Nov 11, 2015 03:24 AM | Tags: experimental community

Another trip report of the last meeting in Kona:

Trip Report: C++ Standards Meeting in Kona, October 2015

by Botond Ballo

From the article:

Last week I attended a meeting of the ISO C++ Standards Committee in Kona, Hawaii. This was the second committee meeting in 2015; you can find my reports on the past few meetings here (June 2014, Rapperswil), here (November 2014, Urbana-Champaign), and here (May 2015, Lenexa). These reports, particularly the Lenexa one, provide useful context for this post.

The focus of this meeting was primarily C++17. There are many ambitious features underway for standardization, and the time has come to start deciding what which of them will make C++17 and which of them won’t. The ones that won’t will target a future standard, or a Technical Specification (which can eventually also be merged into a future standard). In addition, there are a number of existing Technical Specifications in various stages of completion...

The Variant Saga: A happy ending?

By Axel | Nov 6, 2015 04:32 PM | Tags: intermediate experimental efficiency

Variant is like a union, only it tells you what it currently contains, and it will barf if you try to get something out of it that is does not currently contain. It's the type safe sibling of the union:

variant<double, string> v = 42.;
double d = get<double>(v);

I had proposed a variant many moons ago (N4218). After many discussions it seemed that the committee cannot agree on what the ideal C++ variant would look like. I will resolve this cliffhanger -- but before doing that let me introduce you to some of the key discussion points.

An ideal variant will always contain one of its alternative types. But look at this code snippet:

variant<string, MyClass> v = "ABC";
v = MyClass();

The second line will destroy the old value contained in the variant and construct the new value of a different type. Now suppose that the MyClass construction threw: what will the variant contain? What happens when you call get<1>(v)? What happens when the variant gets destroyed?

We either provide the strong exception guarantee (the variant would still contain the string) -- but this requires double buffering, as for instance boost::variant does. Or we could restrict the alternative types to only those that are nothrow_move_constructible. Or we make this a new state -- "invalid, because the variant has been derailed due to an exception thrown during type changing assignment". Or we say "you shouldn't write code that behaves like this; if you do you're on your own", i.e. undefined behavior. The committee was discussing what to do, and so was The Internet. There are other design decisions -- default construction, visitation etc -- but they are all insignificant compared to how to deal with the throwing, type-changing assignment.

I have tried to present the options and their pros and cons in P0086. In short: it's incredibly difficult and fragile to predict whether a type is_nothrow_move_constructible. And double buffering -- required for a strong exception guarantee -- kills the quest for an efficient variant. But efficiency is one of the main motivations for using a discriminated union.

After the second Library Evolution Working Group (LEWG) review in Lenexa, we got P0088R0: a design that was making this invalid state extremely rare. But if it happened, access to the value would result in undefined behavior. This caused a vivid reaction from the committee members. And from The Internet. Hundreds of emails on the committee email lists. Many many smart and convincing blog posts.

In the end, different parts of the committee strongly supported different designs -- and vetoing other designs. Massive disagreement. So when we came to our C++ Standards Meeting in Kona, it was immediately clear that we needed to expose this to the full committee (and not just LEWG). The expectation was that we would declare variant dead, and keep it locked away for the next five years. At least. (An I would have time to water my fishes again.)

So back to the cliffhanger. On the full committee, Monday evening stage in Kona were David Sankel and I. We presented (and represented) the different design options. While we were discussing with the committee members, live and uncut and on stage, David and I realized that we could make it happen. "The Kona Kompromise": similar to P0088R0, but instead of undefined behavior when extracting the value of such a zombie variant it would just throw!

The Kona Kompromise means that we don't pay any efficiency for the extremely rare case of a throwing move. The interface stays nice and clean. A variant of n alternatives is a "mostly" an n-state type. It offers the basic exception guarantee at no relevant performance loss. It is a safe vocabulary type for every-day use, also for novices. The vast majority of the committee was convinced by this idea. Almost everyone in the room was happy!

Do we have a std::variant now? Not yet. But we are a giant leap closer: variant is now under wording review with the Library Working Group (LWG); I will publish a new revision in the Kona post-mailing (P0088R1). This will get re-reviewed in Jacksonville, first week of March. Once LWG gives the green light, the full committee can vote variant into a Technical Specification (TS) as std::experimental::variant. Now that a large fraction of the committee has expressed its consent (happiness, even!), I expect that this will be in the TS called Library Fundamentals, v3. It might or might not make it into C++17 -- that depends mostly on how quickly I manage to bring P0088 into an acceptable state, and how quickly we will gain use experience with variant.

So there is one thing I'd really appreciate your help with: std::experimental::variant will show up in library implementations near you, likely in their first releases next year. It would be fantastic if you could try it out, and as importantly: give feedback, on the public forums or by contacting me directly (axel@cern.ch). Your feedback will tell us whether the design decisions we took are the right ones, for instance regarding default construction, visitation, performance, and especially converting construction and assignment. As they say here: Mahalo!

Axel Naumann, CERN (axel@cern.ch)

N4556: Pre-Kona WG21 telecon minutes -- Marshall Clow

By Blog Staff | Oct 13, 2015 10:12 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.n4556.txt

Document number: N4556

Date: 2015-10-09

Pre-Kona WG21 telecon minutes

by Marshall Clow

2015-09 pre-Kona mailing available

By Blog Staff | Oct 1, 2015 03:39 AM | Tags: None

The 2015-09 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.

N4551: National Body Comments, Concurrency PDTS -- Barry Hedquist

By Blog Staff | Aug 15, 2015 04:04 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.

Document number: N4551

Date: 2015-08-13

National Body Comments, ISO/IEC PDTS 19571, Technical Specification: C++ Extensions for Concurrency

by Barry Hedquist

N4550: Record of Response: National Body Comments ISO/IEC PDTS 19217: Concepts -- Barry Hedquist

By Blog Staff | Jul 28, 2015 12:00 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.

Document number: N4550

Date: 2015-07-25

Record of Response: National Body Comments ISO/IEC PDTS 19217 Technical Specification: C++ Extensions for Concepts

by Barry Hedquist