New paper: N3722, Resumable Functions -- Niklas Gustafsson, Deon Brewis, Herb Sutter, Sana Mithani

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

Date: 2013-08-30

Resumable Functions

by Niklas Gustafsson, Deon Brewis, Herb Sutter, Sana Mithani

Excerpt:

While presenting a proposal that can be adopted or rejected in isolation, this document is related to N3721. The reader is advised to read both as a unit and to consider how the two build on each other for synergy. Reading them in their assigned numeric order is strongly advised.

New in this version: proposed wording for a TS, including language to generalize its applicability to other types than future/shared_future; a section on a possible extension to include generator functions; going back to use of the word ‘resumable’ instead of ‘async’ as the syntactic marker of resumable functions.

New paper: N3721, Improvements to std::future and Related APIs -- Gustafsson Laksberg Sutter Mithani

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

Date: 2013-08-30

Improvements to std::future and Related APIs

by Niklas Gustafsson, Artur Laksberg, Herb Sutter, Sana Mithani

Excerpt:

This proposal is an evolution of the functionality of std::future/std::shared_future. It details additions which can enable wait free compositions of asynchronous operations.

This document supersedes N3634: the title has been changed, and the proposed changes have been modified to be expressed as edits to the C++ Draft Standard.

New in this version: implicit unwrapping (one level) of future<future<R>> to future<R> in then().

... C++ suffers an evident deficit of asynchronous operations compared to other languages, thereby hindering programmer productivity. JavaScript on Windows 8 has promises (then, join and any), .NET has the Task Parallel Library (ContinueWith, WhenAll, WhenAny), C#/VB has the await keyword (asynchronous continuations), and F# has asynchronous workflows. When compared to these languages, C++ is less productive for writing I/O-intensive applications and system software. In particular writing highly scalable services becomes significantly more difficult. ...

Revisiting the BlackBerry 10 NDK

I've been looking at the BlackBerry 10 NDK the last weeks, and did write about it to share some thoughts and results.

Revisiting the BlackBerry 10 NDK

by Jens Weller

From the article:

The last few weeks I did look again at the BlackBerry 10 NDK, as a client had asked for help and training. I offered to adapt my Qt Introduction course to the BlackBerry plattform, and offered my advice...

Before I start, a short paragraph about Apps and C++. People coming from Java or .NET often don't understand the need to make Apps in C++...

New paper: N3744, Proposing [[pure]] -- Walter Brown

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

Date: 2013-08-30

Proposing [[pure]]

by Walter Brown

Excerpt:

Following significant prior art, this paper proposes a pure attribute to specify that a function
or statement is free of observable side effects.

New paper: N3743, Conditionally-supported Special Math Functions for C++14, v2 -- Walter Brown

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

Date: 2013-08-30

Conditionally-supported Special Math Functions for C++14, v2

by Walter Brown

Excerpt:

This paper proposes to merge International Standard 29124:2010, “Extensions to the C++
Library to support mathematical special functions,” into C++14 as a conditionally-supported
standard library feature.

New paper: N3742, Three <random>-related Proposals, v2 -- Walter Brown

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

Date: 2013-08-30

Three <random>-related Proposals, v2

by Walter Brown

Excerpt:

This paper proposes (1) to add one function template to <algorithm>, (2) to add a few novice-friendly
functions to <random>, and (3) to deprecate some related <cstdlib> legacy interfaces.
The unifying factor in this tripartite proposal is the entities’ respective connection with the
random number component of the C++11 standard library.

New paper: N3741, Toward Opaque Typedefs for C++1Y, v2 -- Walter Brown

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

Date: 2013-08-30

Toward Opaque Typedefs for C++1Y, v2

by Walter Brown

Excerpt:

Although this paper is self-contained, it logically follows our discussion, begun several years ago in
N1706 and continued in N1891, of a feature oft-requested for C++: an opaque typedef, sometimes
termed a strong typedef. The earlier of those works was presented to WG21 on 2004-10-20 during
the Redmond meeting, and the later work was presented during the Berlin meeting on 2005-04-06.
Both presentations resulted in very strong encouragement to continue development of such a
language feature. Alas, the press of other obligations has until recently not permitted us to
resume our explorations.

Now with C++11 as a basis, we return to the topic. Where our earlier thinking and nomenclature
seem still valid, we will repeat and amplify our exposition; where we have new insights, we will
follow our revised thinking and present for EWG discussion a high-level proposal for a C++1Y
language feature to be known as an opaque alias. ...

New paper: N3740, A Proposal for the World’s Dumbest Smart Pointer, v2 -- Walter Brown

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

Date: 2013-08-30

A Proposal for the World’s Dumbest Smart Pointer, v2

by Walter Brown

Excerpt:

We present the following code as a preliminary specification of intent in order to serve as a
basis for technical discussion. Designed as a pointer that takes no formal notice of its pointee’s
lifetime, this not-very-smart pointer template is intended as a replacement for near-trivial uses of
bare/native/raw/built-in/dumb C++ pointers, especially when used to communicate with (say)
legacy code that traffics in such pointers. It is, by design, exempt (hence its working name) from
any role in managing any pointee, and is thus freely copyable independent of and without regard
for its pointee.

We have found that such a template provides us a standard vocabulary to denote non-owning
pointers, with no need for further comment or other documentation to describe the near-vacuous
semantics involved...

Quick Q: How is std::function implemented? -- StackOverflow

Quick A: Using type erasure.

Quick Q2: ... Um, what's that?

Quick A2: Read this post...

How is std::function implemented?

According to the sources I have found, a lambda expression is essentially implemented by the compiler creating a class with overloaded function call operator and the referenced variables as members. This suggests that the size of lambda expressions varies, and given enough references variables that size can be arbitrarily large.

An std::function should have a fixed size, but it must be able to wrap any kind of callables, including any lambdas of the same kind. How is it implemented? If std::function internally uses a pointer to its target, then what happens, when the std::function instance is copied or moved? Are there any heap allocations involved?