October 2014

N4161: Uniform Container Erasure (Revision 1) -- Stephan T. Lavavej

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: N4161

Date: 2014-10-09

Uniform Container Erasure (Revision 1)

by Stephan T. Lavavej

Excerpt:

This is a proposal to add erase_if(container, pred) and erase(container, value), making it easier to eliminate unwanted elements correctly and efficiently.  This updates N4009 (see [1]) which proposed erase_if(), by adding erase() and answering additional questions.  Please see the original proposal for the rationale behind this feature, which is not repeated here.

N4206-08: Evolution Issues Lists -- Ville Voutilainen

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: N4206-08

Date: 2014-10-09

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

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

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

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.

Quick Q: Why is "want speed? pass by value" not recommended? -- StackOverflow

Quick A: Because it performs worse than C++98 for common types like string and vector. The preferred way to optimize for rvalues is to add a && overload.

Fresh on SO:

Why is value taking setter member functions not recommended in Herb Sutter's CppCon 2014 talk (Back to Basics: Modern C++ Style)?

In Herb Sutter's CppCon 2014 talk Back to Basics: Modern C++ Style he refers on slide 28 (a web copy of the slides are here) to this pattern:

class employee {
  std::string name_;
public:
  void set_name(std::string name) noexcept { name_ = std::move(name); }
};

He says that this is problematic because when calling set_name() with a temporary, noexcept-ness isn't strong (he uses the phrase "noexcept-ish").

Now, I have been using the above pattern pretty heavily in my own recent C++ code mainly because it saves me typing two copies of set_name() every time -- yes, I know that can be a bit inefficient by forcing a copy construction every time, but hey I am a lazy typer. However Herb's phrase "This noexcept is problematic" worries me as I don't get the problem here: std::string's move assignment operator is noexcept, as is its destructor, so set_name() above seems to me to be guaranteed noexcept. I do see a potential exception throw by the compiler before set_name() as it prepares the parameter, but I am struggling to see that as problematic.

Later on on slide 32 Herb clearly states the above is an anti-pattern. Can someone explain to me why lest I have been writing bad code by being lazy?

N4177: Multidimensional bounds, index and array_view, revision 4 -- Łukasz Mendakiewicz, Herb Sutter

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: N4177

Date: 2014-10-06

Multidimensional bounds, index and array_view, revision 4

by Łukasz Mendakiewicz and Herb Sutter

Excerpt:

Revision 4 (N4177) contains the following changes: ...

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

Thanks to Stephan T. Lavavej, Matthew Fioravante, Robert Kawulak 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. 

N4178: Proposed resolution for Core Issue 330 -- Jens Maurer

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: N4178

Date: 2014-10-07

Proposed resolution for Core Issue 330: Qualification conversions and pointers to arrays of pointers

by Jens Maurer

Excerpt:

This paper presents the proposed resolution for core issue 330 as reviewed in teleconferences of WG21's Core Working Group, substantially cleaning up the wording around qualification converions. Other than allowing the qualification conversions asked for in the issue, it also changes reinterpret_cast so that it may now cast away constness. For example,

reinterpret_cast<int *>((const void *)0)

is ill-formed in C++14 due to the provision in 5.2.10 [expr.reinterpret.cast] paragraph 2 "The reinterpret_cast operator shall not cast away constness (5.2.11 expr.const.cast)". The wording changes below will remove this restriction, thus the example above will become well-formed. Given the general nature of reinterpret_cast, the restriction on casting away constness appeared as a rather odd constraint. 

N4171: Parameter group placeholders for bind -- Tomasz Kamiński

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: N4171

Date: 2014-10-05

Parameter group placeholders for bind

by Tomasz Kamiński

Excerpt:

The aim of this proposal is to introduce a new class of placeholder that could be used with std::bind: a group placeholder that represents a set of (zero or more) call arguments.

This paper addresses LEWG Bug 40: variadic bind.

N4170: Extend INVOKE to support types convertible to target class (Revision 1) -- Tomasz Kamiński

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: N4170

Date: 2014-08-12

Extend INVOKE to support types convertible to target class (Revision 1)

by Tomasz Kamiński

Excerpt:

This proposal extends the definition of INVOKE for class member pointers to cover types convertible to the target class of the pointer, like std::reference_wrapper.

Proposal also resolves LWG issue #2219

N4169: A proposal to add invoke function template (Revision 1) -- Tomasz Kamiński

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: N4169

Date: 2014-08-22

A proposal to add invoke function template (Revision 1)

by Tomasz Kamiński

Excerpt:

The aim of this proposal is to introduce the function template invoke that provide uniform semantics for invoking all C++ callable types which includes: function pointers, member pointers and functors. The behaviour of the function is defined in terms of INVOKE expression.

N4168: Removing auto_ptr -- Billy Baker

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: N4168

Date: 2014-10-02

Removing auto_ptr

by Billy Baker

Excerpt:

At Oxford in 2007, N1856 was accepted adding unique_ptr and making auto_ptr deprecated. At CppCon in 2014, Howard Hinnant stated that he would like to see auto_ptr removed from future C++ standards. This paper proposes that auto_ptr be removed entirely. Removing auto_ptr now would give plenty of time before the next C++ standard for code to be updated if necessary.

N4160: Value constraints -- Andrzej Krzemieński

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: N4160

Date: 2014-10-03

Value constraints

by Andrzej Krzemieński

Excerpt:

In this paper we want to analyse how a support for contract programming-like features could be implemented in C++. We use a different term "value constraints" to stress that we do not necessarily want to copy solutions that other imperative programming languages adapt. We want to change the focus from how broken contracts are responded to in run-time, to how contract violations can be detected at compile-time. This is a high-level overview of the problem, and we are not even covering the things like sub-contracting or other interactions with OO features.