N3912: Auto and braced-init-lists, continued -- Ville Voutilainen

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

Date: 2014-02-24

Auto and braced-init-lists, continued

by Ville Voutilainen

Excerpt:

It was reported (with emphasis) by Mikael Kilpeläinen that init-captures deduce types the same way as auto does. This means that direct-initialization using braces in an init-capture will create an initializer_list. The EWG found this harmful, and is proposing a compromise change that differs from N3681 in the sense that direct-initialization using braces would not yield initializer_lists, whereas copy-initialization using braces would. Example: ...

N3947: URI - Proposed Wording (Revision 4) -- Glyn Matthews, Dean Michael Berris

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

Date: 2014-02-28

URI - Proposed Wording (Revision 4)

by Glyn Matthews, Dean Michael Berris

Excerpt:

Revisions to N3827

  1. Reverted normalization invariant and added the normalize member function and uri_normalization_level again.
  2. Added functions for interoperability with std::filesystem::path.
  3. Replaced multiple exception classes with a single exception class, uri_error. The uri_error enum has become uri_error_code.
  4. Updated make_relative and resolve sections.
  5. Removed references to IETF RFC 2732, which, it was pointed out, is superseded by IETF RFC 3986.

Acknowledgements

C++ Network Library users and mailing list

Kyle Kloepper and Niklas Gustafsson for providing valuable feedback and encouragement, and for presenting different versions of this proposal at committee meetings.

Beman Dawes and his Filesystem proposal from which I was influenced strongly in the class design.

Thiago Macieira of Qt for important feedback on the draft proposal.

David Thaler for suggesting corrections to errors in referencing IETF standards.

Wikipedia, for being there.

N3961: A proposal to add shared_mutex (untimed) -- Gor Nishanov

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

Date: 2014-02-25

N3961: A proposal to add shared_mutex (untimed)

by Gor Nishanov

Excerpt:

At the Issaquah ISO C++ meeting of 2014 shared_mutex was renamed to shared_timed_mutex per proposal N3891 to follow the naming precedent set by timed_mutex and recursive_timed_mutex and to leave room for an untimed shared_mutex which can be more efficient on some platforms than shared_timed_mutex.

This paper introduces shared_mutex without timed locking requirement. This paper only includes the proposed wording. For background for shared locking please refer to N3568, N3659 and N3891.

N3949: Scoped Resource - Generic RAII Wrapper for the Standard Library -- P Sommerlad, A L Sandoval

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

Date: 2014-02-28

Scoped Resource - Generic RAII Wrapper for the Standard Library

by Peter Sommerlad and Andrew L. Sandoval

Excerpt:

This proposal introduces a new RAII "smart" resource container called unique_resource_t which can bind a resource to "clean-up" code regardless of type of the argument required by the "clean-up" function.

...

4 Acknowledgements

  • This proposal incorporates what Andrej Alexandrescu described as scope guard long ago and explained again at C++ Now 2012 ().
  • This proposal would not have been possible without the impressive work of Peter Sommerlad who produced the sample implementation during the Fall 2013 committee meetings in Chicago. Peter took what Andrew Sandoval produced for N3677 and demonstrated the possibility of using C++14 features to make a single, general purpose RAII wrapper capable of ful lling all of the needs presented by the original 4 classes (from N3677) with none of the compromises.
  • Gratitude is also owed to members of the LEWG participating in the February 2014 (Issaquah) and Fall 2013 (Chicago) meeting for their support, encouragement, and suggestions that have led to this proposal.
  • Special thanks and recognition goes to OpenSpan, Inc. (http://www.openspan.com) for supporting the production of this proposal, and for sponsoring Andrew L. Sandoval's rst proposal (N3677) and the trip to Chicago for the Fall 2013 LEWG meeting. Note: this version abandons the over-generic version from N3830 and comes back to two classes with one or no resource to be managed.
  • Thanks also to members of the mailing lists who gave feedback. Especially Zhihao Yuan, and Ville Voutilainen.  Special thanks to Daniel Krügler for his deliberate review of the draft version of this paper (D3949).

 

C++ and the Google Summer of Code

I wrote an overview over this years Google Summer of Code and C++

C++ and the Google Summer of Code

by Jens Weller

From the Article:

During the last few weeks I got interested in the Google Summer of Code (GSoC), as I did read some emails on the boost mailing lists about it. The Google Summer of Code is for a lot of open source projects an important opportunity to improve and extend their code base, and in 2014 it happens for the 10th time!

Range Concepts, To Infinity And Beyond

The 4th part in Erics series on ranges:

Range Concepts, Part 4 of 4: To Infinity And Beyond

by Eric Niebler

From the Article:

Last time, I introduced a new concept, Iterable, and showed how it solved many of the problems with pair-of-iterator-style ranges. This time around, I’m going to extend Iterable in small ways to make programming with infinite ranges safer and more efficient. Disclaimer: The ideas in this post are more speculative than in the previous three. I’m looking forward to the disucussion.

C++17: I See a Monad in Your Future!

Thoughts on Monads and Futures in C++

C++17: I See a Monad in Your Future!

by Bartosz Milewski

From the Article:

If you thought you were safe from functional programming in your cozy C++ niche, think again! First the lambdas and function objects and now the monad camouflaged as std::future. But do not despair, it’s all just patterns. You won’t find them in the Gang of Four book, but once you see them, they will become obvious.

N3956: ISO/IEC CD 14882, C++ 2014, Responses to National Body Comments -- Barry Hedquist

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.

Note: This document summarizes the responses to all national comments in last year's CD ballot for C++14, which ballot resolution was completed this month at the Issaquah meeting. C++14 is now about to go out for its next ballot stage, DIS (Draft International Standard).

Document number: N3956

Date: 2014-02-24

ISO/IEC CD 14882, C++ 2014, Responses to National Body Comments

by Barry Hedquist

Excerpt:

Attached is a complete set of the WG21 Responses to National Body Comments in response to the SC22 Ballot for ISO/IEC CD 14882, Committee Draft of the revision of ISO/IEC 14882:2011, aka C++ 2014.

Range Concepts, Part 3 of 4: Introducing Iterables

The third part of Eric Nieblers Series on ranges

Range Concepts, Part 3 of 4: Introducing Iterables

by Eric Niebler

From the Article:

In the last two blog posts, I describes the challenges I’ve encountered while building a next-generation range library. In this post, I’ll sketch for you my proposed solution: refinements of the range concepts that allow delimited, infinite, and pair-o’-iterator-style ranges to fit comfortably within the concept hierarchy without loss of performance or expressive power and with increased safety. I’ve built a range library around these concepts that subsumes and extends all of the C++98 STL algorithms and the Boost.Range adaptors, so I can say with confidence that these concepts lead to a useful and consistent generic range library.