: Standard C++

Home » Blog » Categories »

« Prev Next »

New paper: N3594, std::join: An Algorithm for Joining a Range of Elements -- Greg Miller

By Blog Staff | Mar 19, 2013 11:24 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: N3594

Date: 2013-03-13

std::join: An Algorithm for Joining a Range of Elements

by Greg Miller

Excerpt:

Creating a string by joining the elements in a collection with a separator between each element is a common task in many applications. Often the elements themselves are strings, so joining them is fairly straight forward. However, it is not uncommon to join collections of types other than string. For example, one might want to log a collection of int identifiers with each value separated by a comma and a space. In this case there needs to be some way to format the collection's element type as a string.

The std::join() API described in this paper describes a function that is easy to use in all the common cases, such as joining strings and string-like objects as well as primitives like int, float, etc. This API is also extensible through a Formatter function object and is able to join arbitrary types.

Joining strings is the inverse of splitting strings and they are often thought of together. This proposal describes a joining function to go along with the std::split() function described in N3593 (std::split).

This proposal depends on or refers to the following proposals:

N3593 (std::split)

N3609 (std::string_view)

N3513 (Range support)

New paper: N3593, std::split(): An Algorithm for Splitting Strings -- Greg Miller

By Blog Staff | Mar 19, 2013 11:21 AM | Tags: None

Document number: N3593

Date: 2013-03-13

std::split(): An Algorithm for Splitting Strings

by Greg Miller

Excerpt:

Splitting strings into substrings is a common task in many applications. When the need arises in C++, programmers must search for an existing solution or write one of their own. A typical solution might look like the following:
    std::vector<std::string> my_split(const std::string& text, const std::string& delimiter);
A straightforward implementation of the above function would likely use std::string::find or std::string::find_first_of to identify substrings and move from one to the next, building the vector to return. This is a fine solution for simple needs, but it is deficient in the following ways:

Must be reimplemented by each individual/organization

Not adaptable to different types of delimiter, such as regular expressions

Not adaptable to different return types, such as std::set<string>

Google developed a flexible and fast string-splitting API to address these deficiencies. The new API has been well received by internal engineers developing serious applications. The rest of this paper describes Google's string splitting API as it might appear as a C++ standard.

This proposal depends on the following proposals:

N3609 (std::string_view)

N3513 (Range support)

New paper: N3592, Alternative Cancellation and Data Escape Mechanisms for Transactions -- T Riegel

By Blog Staff | Mar 19, 2013 11:19 AM | Tags: None

Document number: N3592

Date: 2013-03-15

Alternative Cancellation and Data Escape Mechanisms for Transactions

by Torvald Riegel

Excerpt:

Cancellation refers to the ability to cancel the execution of an atomic transaction: When a transaction cannot or does not want to continue execution until it commits, it can stop execution and roll back the actions done so far as part of the transaction. Conceptually, this has always been a part of transactional systems, for example to ensure failure atomicity (i.e., make sets of operations execute completely or not at all even when some of the operations might fail). Even though Transactional Memory (TM) currently focuses primarily on using transactions for concurrency control and not failure atomicity, there are use cases for the latter too (e.g., guaranteeing program invariants in concurrent settings, or speculative execution).

In what follows, I will describe cancellation and data escape mechanisms for transactions as specified by the current draft specification and the changes summarized in N3589. These are supposed to replace the cancellation mechanisms in the current draft (i.e., the __transaction_cancel keyword and the cancel-and-throw functionality); they are compatible with the minimal exceptions proposal described in N3589. The data escape mechanisms allow transaction to communicate data out of cancelled transactions (i.e, the data escapes the transaction's atomicity). Also, whenever I refer to transactions, this always means atomic transactions, not the relaxed transaction variant.

The cancellation mechanisms described here are supposed to serve as a foundation for higher-level features that make use of cancellation, such as composable forms of error recovery or more focused kinds of speculative execution. They also try to provide cancellation with no language extensions or changes (besides a minor extension to the syntax of transaction statements); most of the functionality can be expressed as library features. Likewise, it can be implemented in just the TM-specific implementation parts.

New paper: N3588, make_unique -- Stephan T. Lavavej

By Blog Staff | Mar 19, 2013 11:14 AM | Tags: None

Document number: N3588

Date: 2013-03-15

make_unique

by Stephan T. Lavavej

Excerpt:

I. Introduction

This is a proposal to add make_unique for symmetry, simplicity, and safety.

II. Motivation And Scope

C++11 provided make_shared for shared_ptr, but not make_unique for unique_ptr. This is widely viewed as an oversight. While it isn't absolutely necessary for the Standard to provide make_unique (because skilled users can implement it with perfect efficiency), it's still important. The implementation of make_unique<T>(args...), a perfectly forwarding variadic template, is difficult for beginners to understand. make_unique<T[]> involves even more subtleties. Because make_unique is commonly desired, adding it to the Standard Library will put an end to the proliferation of user implementations.

make_unique's presence in the Standard Library will have several wonderful consequences. It will be possible to teach users "never say new/delete /new[]/delete[]" without disclaimers. Additionally, make_unique shares two advantages with make_shared (excluding the third advantage, increased efficiency). First, unique_ptr<LongTypeName> up(new LongTypeName(args)) must mention LongTypeName twice, while auto up = make_unique<LongTypeName>(args) mentions it once. Second, make_unique prevents the unspecified-evaluation-order leak triggered by expressions like foo(unique_ptr<X>(new X), unique_ptr<Y>(new Y)). (Following the advice "never say new" is simpler than "never say new, unless you immediately give it to a named unique_ptr".)

New paper: N3587, For Loop Exit Strategies -- Alan Talbot

By Blog Staff | Mar 19, 2013 11:12 AM | Tags: None

Document number: N3587

Date: 2013-03-17

For Loop Exit Strategies

by Alan Talbot

Excerpt:

This proposal suggests an enhancement to for iteration statements to allow the programmer to specify separate blocks of code that execute on completion of a for loop; one for normal termi-nation (when the loop condition is no longer met) and the other for early termination (when the loop is exited with a break). This feature would be especially useful in range-based for statements.

New paper: N3586, Splicing Maps and Sets -- Alan Talbot, Howard Hinnant

By Blog Staff | Mar 19, 2013 11:09 AM | Tags: None

Document number: N3586

Date: 2013-03-17

Splicing Maps and Sets

by Alan Talbot, Howard Hinnant

Excerpt:

This is an enhancement to the associative and unordered associative containers to support the manipulation of nodes. It is a pure addition to the Library.

The key to the design is a new function remove which unlinks the selected node from the container (performing the same balancing actions as erase).

New paper: N3585, Iterator-Related Improvements to Containers (Revision 2) -- Alan Talbot

By Blog Staff | Mar 19, 2013 11:08 AM | Tags: None

Document number: N3585

Date: 2013-03-17

Iterator-Related Improvements to Containers (Revision 2)

by Alan Talbot

Excerpt:

This proposal recommends several small enhancements to the way containers interact with iterators. While none of these introduces functionality that cannot be achieved by other means, they make containers easier to use and teach, and make user code smaller and easier to read.

New paper: N3584, Wording for Addressing Tuples by Type -- Mike Spertus

By Blog Staff | Mar 19, 2013 11:07 AM | Tags: None

Document number: N3584

Date: 2013-03-14

Wording for Addressing Tuples by Type

by Mike Spertus

Excerpt:

In Portland, LWG accepted the "Addressing tuples by type" portion of n3404, pending wording, which is provided below. Note that the "Functoriality" proposal in that paper was not accepted.

New paper: N3582, Return Type Deduction for Normal Functions (Revision 3) -- Jason Merrill

By Blog Staff | Mar 19, 2013 11:02 AM | Tags: intermediate experimental

[Ed.: Also of broad interest and on track for near-term standardization.]

Document number: N3582

Date: 2013-03-15

Return Type Deduction for Normal Functions (Revision 3)

by Jason Merrill

Excerpt:

Any C++ user introduced to the C++11 features of auto, lambdas, and trailing return types immediately wonders why they can't just write auto on their function declaration and have the return type deduced. This functionality was proposed previously in N2954, but dropped from C++11 due to time constraints, as the drafting didn't address various questions and concerns that the Core WG had. I have now implemented this functionality in GCC, and propose to add it to C++14. I discuss some of the less obvious aspects of the semantics below.

This proposal also resolves core DRs 975 (lambda return type deduction from multiple return statements) and 1048 (inconsistency between auto and lambda return type deduction).

New paper: N3581, Delimited Iterators -- Mike Spertus

By Blog Staff | Mar 19, 2013 10:59 AM | Tags: None

Document number: N3581

Date: 2013-03-16

Delimited iterators

by Mike Spertus

Excerpt:

It is extremely tempting to use ostream_iterator to, say, print a vector like:
vector v = {1, 4, 6}; 
cout << "("; 
copy(v.begin(), v.end(), ostream_iterator(cout, ", ")); 
cout << ")"; // Oops! Prints (1, 4, 6, )
The problem is that the “delimiter” in the ostream_iterator constructor call is better described as a suffix than a delimeter.

We offer two alternate proposals.