PO4116r0: Completing support for emotive programming in C++ -- Pablo Halpern

By Blog Staff | Apr 1, 2016 02:00 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: PO4116r0

Date: 2016-04-01

Completing support for emotive programming in C++

by Pablo Halpern

Excerpt:

There can be no doubt that C++ is an unusually expressive language. A significant part of that expressiveness comes from the ability to use emoticons, not just in comments and string literals, but in the code itself. For example the following (do-nothing) program compiles, links, and runs in all versions of C++: ...

P3141: std::terminates()

By Blog Staff | Apr 1, 2016 01:00 AM | Tags: None

A new WG21 paper is available.

Document number: P3141

Date: 2016-04-01

std::terminates()

by Hal T. Ng, Professor, C.S., LLVM.edu

Excerpt:

In 2014, the C++ committee tackled the problem of C++98's subtly hard-to-use std::uncaught_exception(), which was intended to return whether there were unhandled exceptions but did not work as intended in all destructor cases. The committee successfully addressed the problem by providing the improved std::uncaught_exceptions() (note plural "s"), which returns the number of unhandled exceptions in the current thread, and this function can now be used to reliably implement scope_guard and similar patterns in portable code.

Continuing in the same vein, this paper proposes to address C++98's related and sometimes-problematic std::terminate(). As its name suggests, the function causes abrupt program halts, which can cause data corruption if operations in flight are not completed gracefully. The set_terminate_handler() facility only partly addresses this problem by allowing a last-ditch handler to be invoked after unstoppable termination has already begun.

Along the same lines as conditional noexcept (noexcept(cond)), we propose a way for a sensitive operation, or a whole program, to determine in advance whether termination is possible. A program can test this by calling:

namespace std {
    bool terminates();
}

which returns true if and only if the program can subsequently terminate.

Because this function cannot fail to determine a valid result, it should be noexcept. Further, anticipating its usefulness in constant expressions and following LWG’s guidance for using constexpr wherever possible throughout the standard library, we propose in full:

namespace std {
    constexpr bool terminates() noexcept;
} 

Implementation notes: This function is so simple to specify that we foresee no implementation difficulty in any of the major C++ compilers.

Note that this is not the same as the halting problem, which would be to return true if and only if the program will halt, and which is known to take several hours to compute for programs longer than a few tens of millions of lines. Rather, this function is carefully constructed to return true if and only if the program could terminate, which is fundamentally different and well understood problem.

Acknowledgments: This paper expands on the core idea that was first proposed in committee hallway discussion by P.J. Plauger.

Trip Report: C++ Standards Meeting in Jacksonville, February 2016--Botond Ballo

By Adrien Hamelin | Mar 25, 2016 04:33 AM | Tags: experimental community

ANother trip report:

Trip Report: C++ Standards Meeting in Jacksonville, February 2016

by Botond Ballo

From the article:

Last week I attended a meeting of the ISO C++ Standards Committee in Jacksonville, Florida. This was the first committee meeting in 2016; you can find my reports on the 2015 meetings here (May 2015, Lenexa) and here (October 2015, Kona). These reports, particularly the Kona one, provide useful context for this post...

P0141R0: Modules, Componentization, and Transition by Gabriel Dos Reis and Pavel Curtis

By Blog Staff | Mar 22, 2016 05:44 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: P0141R0

Date: 2015-10-05

Modules, Componentization, and Transition

by Gabriel Dos Reis and Pavel Curtis

Excerpt:

We provide an analysis of constraints for a good, acceptable, and scalable module system for modern C++. This analysis is based on decades of practical experience with precompiled headers, and 40+ years of the include-file model, which has shown its limits. The paper also discusses several migration strategies. The end goal is to stimulate a technical discussion about the difficult choices we face in bringing C++’s compilation model into the era of semantics-aware developer tools, and of smart distributed and cloud build systems.

P0221R1: Proposed wording for default comparisons, revision 3 -- Jens Maurer

By Blog Staff | Mar 18, 2016 09:32 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: P0221R1

Date: 2016-03-17

P0221R1: Proposed wording for default comparisons, revision 3

by Jens Maurer

Excerpt:

Introduction

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.

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).

P0221R0 amended by a clarification for template specializations was approved by EWG during the Jacksonville (2016-03) meeting of WG21. Blue text in the proposed wording indicates changes compared to P0221R0.

Changes since P0221R0

• fix wording glitches
• clarified the zero-subobject (= empty class) cases
• clarified that the context for a subobject comparison is the top-level class definition
• clarified that both slicing copy and slicing move are prohibited
• two-phase name lookup applies when comparing members whose type was instantiated from a dependent type

P0206R1: A joining thread -- Ville Voutilainen

By Blog Staff | Mar 18, 2016 09:28 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: P0206R1

Date: 2016-03-09

A joining thread

by Ville Voutilainen

Excerpt:

Changes from previous version

• This paper revises P0206R0.
• Removed the motivation elaboration, it can be found in the previous revision.
• Removed the discarded solutions.
• Added explanation for the std::thread-accessing functions and discarded alternatives for it.
• Renamed safe_thread to joining_thread.
• Used thread::id and thread::native_handle_type in joining_thread.
• Updated proposed wording.

Abstract

C++ continues not to provide a thread type that would join() automatically on scope exit. This causes exception-safety problems, because failing to join() in all code paths causes the destructor of a std::thread to terminate(). This paper provides a solution that adds a new thread type that joins in its destructor, and is based on large-group and LEWG feedback given in Jacksonville. The proposal has been implemented and tested. 

Jacksonville approved papers and issues

By Blog Staff | Mar 11, 2016 04:05 PM | Tags: None

The following is a list of the papers approved at the Jacksonville meeting that ended on Saturday. Some of the papers appeared in the pre-meeting mailing or an earlier mailing; most were updated during the meeting and for convenience this post includes and links to copies of the approved papers. All updated approved papers will appear also in the official post-meeting mailing, as will the official minuted form of the following notes.

More readable summaries will be posted in trip reports. This post is primarily making the papers available for linking and reference.

Accept as Defect Reports the issues in P0167R2 (Core Language "ready" Issues) and apply their proposed resolutions to the C++ working paper.

Accept as Defect Reports the issues in P0263R1 (Core Language "tentatively ready" Issues) and apply their proposed resolutions to the C++ working paper.

Apply to the C++ working paper the proposed wording in P0188R1 ("Wording for [[fallthrough]] attribute").

Apply to the C++ working paper the proposed wording in P0189R1 ("Wording for [[nodiscard]] attribute").

Apply to the C++ working paper the proposed wording in P0212R1 ("Wording for [[maybe_unused]] attribute").

Apply to the C++ working paper the proposed wording in P0017R1 ("Extension to aggregate initialization").

Apply to the C++ working paper the proposed wording in P0170R1 ("Wording for Constexpr Lambda").

Apply to the C++ working paper the proposed wording in P0036R0 ("Unary Folds and Empty Parameter Packs (revision 1)").

Apply to the C++ working paper the proposed wording in P0184R0 ("Generalizing the Range-Based For Loop").

Apply to the C++ working paper the proposed wording in P0018R3 ("Lambda Capture of *this by Value as [=,*this]").

Apply to the C++ working paper the proposed wording in P0138R2 ("Construction Rules for enum class Values").

Apply to the C++ working paper the proposed wording in P0245R1 ("Hexadecimal floating literals for C++").

Request a new work item for a Technical Specification on C++ Extensions for Modules and create a working paper with P0143R2 ("Wording for Modules") as its initial content.

Apply the resolutions of the following issues in "Ready" status from P0165R1 to the C++ Working Paper:

Note that the following issues, marked Ready in the paper, are not being advanced:

Apply the resolutions of the following issues in "Tentatively Ready" status from P0165R1 to the C++ Working Paper:

Apply the resolutions of the following issues in "Tentatively Ready" status from P0165R1 to the Library Fundamentals Working Paper:

Apply to the C++ Working Paper the Proposed Wording from P0024R2, The Parallelism TS Should be Standardized.

Apply to the C++ Working Paper the Proposed Wording from P0226R1, Mathematical Special Functions for C++17, v5.

Apply to the C++ Working Paper the Proposed Wording from P0220R1, Adopt Library Fundamentals V1 TS Components for C++17 (R1).

Apply to the C++ Working Paper the Proposed Wording from P0218R1, Adopt the File System TS for C++17.

Apply to the C++ Working Paper the Proposed Wording from P0033R1, Re-enabling shared_from_this (revision 1).

Apply to the C++ Working Paper the Proposed Wording from P0005R4, Adopt not_fn from Library Fundamentals 2 for C++17.

Apply to the C++ Working Paper the Proposed Wording from P0152R1, constexpr atomic::is_always_lock_free.

Apply to the C++ Working Paper the Proposed Wording from P0185R1, Adding [nothrow-]swappable traits, revision 3.

Apply to the C++ Working Paper the Proposed Wording from P0253R1, Fixing a design mistake in the searchers interface.

Apply to the C++ Working Paper the Proposed Wording from P0025R0, An algorithm to "clamp" a value between a pair of boundary values.

Apply to the C++ Working Paper the Proposed Wording from P0154R1, constexpr std::hardware_{constructive,destructive}_interference_size.

Apply to the C++ Working Paper the Proposed Wording from option #2 in P0030R1, Proposal to Introduce a 3-Argument Overload to std::hypot.

Apply to the C++ Working Paper the Proposed Wording from P0031R0, A Proposal to Add Constexpr Modifiers to reverse_iterator, move_iterator, array and Range Access and apply the resolution of LWG Issue 2296 - std::addressof should be constexpr. This issue is published in P0304R0.

Apply to the C++ Working Paper the Proposed Wording from P0272R1, Give 'std::string' a non-const '.data()' member function.

Apply to the C++ Working Paper the Proposed Wording from P0077R2, is_callable, the missing INVOKE related trait.

C++17 and other future highlights of C++

By Meeting C++ | Mar 10, 2016 08:18 AM | Tags: standardization experimental c++17 advanced

The last and final part about the current proposals for C++17:

C++17 and other future highlights of C++

by Jens Weller

From the article:

Welcome to the 3rd and last part about current proposals for C++17 and beyond...

Trip Report C++ Meeting at Jacksonville -- J. Daniel Garcia

By Felix Petriconi | Mar 6, 2016 12:17 PM | Tags: None

Here is Daniel's trip report from the recent C++ meeting at Jacksonville

Trip Report C++ Meeting at Jacksonville

by J. Daniel Garcia

From the article:

First of all the bad news. Unfortunately I have to say that the outcome of the standards meeting has been disappointing. Let me explain myself. We had a really very intense week here in Jacsonville. We made progress in many things, but  we will not have the killer features I really wanted for C++17.

In detail he sums the features that were not voted into C++17 and those that were accepted.

C++17 and its Technical Specifications

By Meeting C++ | Mar 3, 2016 08:50 AM | Tags: standardization intermediate experimental c++17 advanced

The 2nd part of my series on proposals for C++17 deals with Technical Specifications:

C++17 and its Technical Specifications

by Jens Weller

From the article:

Part 2 of my series about the current proposals for C++17. This part is covering the Technical Specifications (TS), which are currently released. Some of them will make it into C++17. Those not making it into C++17...