Home » Blog » Categories » Standardization

Standardization

N4059: Spring 2015 C++ Standards Committee Meeting -- Michael Price

By Blog Staff | Jul 3, 2014 01:01 PM | Tags: None

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4059

Date: 2014-07-03

Spring 2015 C++ Standards Committee Meeting

by Michael Price

Excerpt:

Perceptive Software is pleased to host the Spring 2015 C++ Standards Committee Meeting on May 4-9, 2015.

Meeting location

Perceptive Software World Headquarters
8900 Renner Blvd.
Lenexa, Kan. 66219

(Located within the Kansas City metropolitan area)

N4073: A Proposal to Add 2D Graphics Rendering and Display to C++, Rev 2 -- McLaughlin, Sutter, Zink

By Blog Staff | Jul 3, 2014 12:04 PM | Tags: None

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4073

Date: 2014-07-03

A Proposal to Add 2D Graphics Rendering and Display to C++, Revision 2

by Michael B. McLaughlin, Herb Sutter, Jason Zink

Excerpt:

The goal of this proposal is to define a 2D drawing API for the C++ programming language. This proposal is a revision of N4021. It resolves some defects in that document and adds several features which were intended for N4021 but were not completed in time. It was presented in draft form to SG13 at the Rapperswil meeting in June 2014. Based on the consensus feedback received at the meeting, a full Technical Specifications section written in the language, style, and format of the ISO/IEC C++ Standard will be included in the next revision of this proposal.

N4116: Nested Namespace Definition (rev 1) -- Andrew Tomazos and Robert Kawulak

By Blog Staff | Jul 3, 2014 08:40 AM | Tags: None

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4116

Date: 2014-07-02

Nested Namespace Definition (rev 1)

by Andrew Tomazos and Robert Kawulak

Excerpt:

EWG did meet and discuss N4026 in Rapperswil, including each of the open issues. Several
different votes were taken. By far the strongest consensus was for just the basic facility with no
attributes, no aliases and no inline:

SF: 11 F: 5 N: 3 A: 0 SA: 0

Furthermore, if it is implemented in this configuration, these extra features can always be added
later by a separate proposal.

We therefore formally propose that the following wording corresponding to the “basic facility” be
added to the working draft: ...

N4055: Ruminations on (node-based) containers and noexcept -- Ville Voutilainen

By Blog Staff | Jul 3, 2014 08:10 AM | Tags: None

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4055

Date: 2014-07-02

Ruminations on (node-based) containers and noexcept

by Ville Voutilainen

Excerpt:

There are quite many standard containers that do not have noexcept move constructors required by their synopsis. Implementations can strengthen such a noexcept-specification as per [res.on.exception.handling]/1: "Any of the functions defined in the C ++ standard library can report a failure by throwing an exception of a type described in its Throws: paragraph. An implementation may strengthen the exception-specification for a non-virtual function by adding a non-throwing noexcept-specification."

The issue is that this means that the performance of operations such as vector<T>::push_back becomes dependent on the noexcept-specification of the move constructor of T, and if T has a container member, the noexcept-specification of that container influences the noexcept-specification of the move constructor of T in implementation-specific ways.

This paper explores the reasons of why container move constructors are not noexcept on some implementations. A very good explanation is written below.

This paper also makes some moderate suggestions on what the solution(s) should be.

Nicolai Josuttis proposes some of those moderate suggestions in his paper N4002.

N4113: Reflection Type Traits For Classes, Unions and Enumerations (rev 3) -- A. Tomazos, C. Kaeser

By Blog Staff | Jul 2, 2014 04:23 PM | Tags: None

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4113

Date: 2014-07-02

Reflection Type Traits For Classes, Unions and Enumerations (rev 3)

by Andrew Tomazos and Christian Kaeser

Excerpt:

We propose the addition of two new kinds of type trait, and four new type traits to the Metaprogramming and Type Traits Standard Library [meta] for the purposes of lowlevel reflection of classes, unions and enumerations. These primitives are thin wrappers for compiler instrinsics, require zero core language changes, and are designed to be consistent with the existing [meta] library. Pure library authors can then compose the primitives to provide higher-level reflection libraries and facilities.

This proposal revises N4027 in accordance with SG7 feedback from Rapperswil (N4027 revises
N3815 with SG7 feedback from Issequah).

N4101-03: Evolution Issues Lists -- Ville Voutilainen

By Blog Staff | Jul 1, 2014 08:08 PM | Tags: None

New WG21 papers are available. Copies are linked below, and will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document numbers: N4101-03

Date: 2014-07-01

C++ Standard Evolution Active Issues List (Revision R08)

C++ Standard Evolution Completed Issues List (Revision R08)

C++ Standard Evolution Closed Issues List (Revision R08)

by Ville Voutilainen

Excerpt:

The purpose of this document is to record the status of issues which have come before the Evolution Working Group (EWG) of the INCITS PL22.16 and ISO WG21 C++ Standards Committee. Issues represent potential defects in the ISO/IEC IS 14882:2003(E) document, and proposed extensions to it.

N4087: Multidimensional bounds, index and array_view, revision 3 -- Łukasz Mendakiewicz, Herb Sutter

By Blog Staff | Jul 1, 2014 08:04 PM | Tags: None

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4087

Date: 2014-07-01

Multidimensional bounds, index and array_view, revision 3

by Łukasz Mendakiewicz and Herb Sutter

Excerpt:

Overview

Revision 3 incorporates the feedback received in Rapperswil from LEWG and some other minor fixes: ...

Acknowledgements

Thanks to Stephan T. Lavavej and the members of LEWG for the suggested improvements. Thanks to the interlocutors at ISO C++ Standard -- Future Proposals forum for the valuable feedback. Thanks to all correspondents expressing feedback in private emails.

N4058: Atomic Smart Pointers -- Herb Sutter

By Blog Staff | Jun 12, 2014 10:21 AM | Tags: None

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4058

Date: 2014-06-12

Atomic Smart Pointers

by Herb Sutter

Excerpt:

We encourage that modern C++ code should avoid all uses of owning raw pointers and explicit delete. Instead, programmers should use unique_ptr and shared_ptr (with weak_ptr), as this is known to lead to simpler and leak-free memory-safe code. This is especially important when lifetimes are unstructured or nondeterministic, which arises especially in concurrent code, and it has long been well-known that the smart pointers would be useful there; for an example, see [1].

Unfortunately, lock-free code is still mostly forced to use owning raw pointers. Our unique_ptr, shared_ptr, and weak_ptr would directly benefit lock-free code just as they do regular code (see next section), but they are not usable easily or at all in lock-free code because we do not support atomic<unique_ptr<T>>, atomic<shared_ptr<T>>, and atomic<weak_ptr<T>>.

...

If we had atomic<unique_ptr<T>> we could (and should) write the following equivalent code that is safer, no slower, and less error-prone because we can directly express the unique ownership semantics including ownership transfer:

atomic<unique_ptr<X>> p_root;
void producer() {
    auto temp = make_unique<X>();
    load_from_disk_and_store_in( *temp ); // build data structure
    p_root = move(temp);                  // atomically publish it
}
This righteous code should be supported...