N4183: Contiguous Iterators: Pointer Conversion & Type Trait -- Nevin Liber

By Blog Staff | Oct 10, 2014 02:40 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: N4183

Date: 2014-10-10

Contiguous Iterators: Pointer Conversion & Type Trait

by Nevin Liber

Excerpt:

This is a proposal to:

• Add a mechanism for converting a contiguous iterator to a pointer
• A type trait for contiguous iterators

It builds upon the discussion in Issaquah on the previous version of this paper (n3884) and is dependent on n4132 Contiguous Iterators by Jens Maurer.

N4190: Removing auto_ptr, random_shuffle(), And Old Stuff -- Stephan T. Lavavej

By Blog Staff | Oct 10, 2014 02:37 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: N4190

Date: 2014-10-09

Removing auto_ptr, random_shuffle(), And Old Stuff

by Stephan T. Lavavej

Excerpt:

The C++ Standard is big.  We should make it smaller by removing stuff we don't need anymore, like features that have been deprecated for years and thoroughly superseded by more modern machinery.

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

By Blog Staff | Oct 10, 2014 02:34 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: 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

By Blog Staff | Oct 9, 2014 08:54 AM | 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: 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

By Blog Staff | Oct 9, 2014 08:41 AM | Tags: basics

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

By Blog Staff | Oct 9, 2014 12:43 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: 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

By Blog Staff | Oct 8, 2014 01:56 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: 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

By Blog Staff | Oct 8, 2014 01:52 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: 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

By Blog Staff | Oct 8, 2014 01:49 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: 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

By Blog Staff | Oct 8, 2014 01: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: 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.