Home » Blog » Categories »

Quick Q: Why use C varargs when you have initializer_lists and variadic templates? -- StackOverflow

By Blog Staff | Mar 18, 2013 02:06 PM | Tags: basics

Quick A: No reason, varargs are type-unsafe and entirely superseded by C++11 features (unless you need C compatibility).

Why use variadic arguments now when initializer lists are available?

I've been wondering what are the advantages of variadic arguments over initializer lists. Both offer the same ability -- to pass indefinite number of arguments to a function.

 

What I personally think is initializer lists are a little more elegant. Syntax is less awkward.

Also, it appears that initializer lists have significantly better performance as the number of arguments grows.

 

So what am I missing, besides the possibility to use use variadic arguments in C as well?

New paper: N3560, Proposal for Assorted Extensions to Lambda Expressions -- Faisal Vali et al.

By Blog Staff | Mar 18, 2013 11:20 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: N3560

Date: 2013-03-17

Proposal for Assorted Extensions to Lambda Expressions

by Faisal Vali, Herb Sutter, Dave Abrahams

Excerpt:

We propose extensions to lambda expressions motivated by the general view that lambda expressions should allow for a concise and complete description of a callable unit of computation. In addition to containing those features from document N3418: Proposal for Generic (Polymorphic) Lambda Expressions that received against votes in Portland (2012), it also contains other small extensions to lambdas. We also present our experience implementing some of the features using Clang.

... The aim of this paper is to propose various extensions to lambda expressions (generic and non-generic) to simplify and enhance their use. This proposal builds on N3559 (which defines a generic lambda). We assume the reader is familiar with C++11 lambdas and the content of N3559.

It is important to note that not all the authors of this paper are in favor of each and every one of these proposed features and the purpose of this paper is to seek guidance from the EWG regarding which features are worth pursuing further.

New paper: N3559, Proposal for Generic (Polymorphic) Lambda Expressions (Rev. 2) -- F. Vali et al.

By Blog Staff | Mar 18, 2013 11:17 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: N3559

Date: 2013-03-17

Proposal for Generic (Polymorphic) Lambda Expressions (Revision 2)

by Faisal Vali, Herb Sutter, Dave Abrahams

Excerpt:

This document revises N3418: Proposal for Generic (Polymorphic) Lambda Expressions and incorporates feedback from the Evolution Working Group (Portland, October 2012). In this revision we propose the two features that received no opposing votes from the EWG (with the other features described in a separate document). Specifically, we propose that auto be required in a lambda-expression's parameter-declaration-clause to identify a generic lambda; and that a generic lambda with no lambda-captures contain a conversion function template to an appropriate pointer-to-function. After a brief discussion of the features (with details deferred to the Appendices), we describe standard wording. All the features proposed in this document have been implemented using clang.

New paper: N3592, Alternative Proposal for Cancellation and Exceptions -- Torvald Riegel

By Blog Staff | Mar 16, 2013 03:54 PM | 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: N3592

Date: 2013-03-15

Alternative Proposal for Cancellation and Exceptions

by Torvald Riegel

Excerpts:

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). ...

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. ...

At first sight, it might look like cancellation and exception handling are more or less the same. I disagree with that, and will briefly argue in what follows that they are sufficiently different to justify having separate mechanisms for both. ...

 

New paper: N3591, Summary of Discussions on Explicit Cancellation in Transactional Lang Constructs

By Blog Staff | Mar 16, 2013 03:51 PM | 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: N3591

Date: 2013-03-15

Summary of Discussions on Explicit Cancellation in Transactional Language Constructs for C++

by Hans Boehm, Justin Gottschlich, Victor Luchangco, Maged Michael, Mark Moir, Torvald Riegel, Michael Scott, Michael Spear, Tatiana Shpeisman, Michael Wong

Excerpt:

This document summarizes discussions in the SG5 Transactional Memory Study Group on ideas for supporting explicit cancellation of atomic transactions. While we have not reached agreement on whether to support such features or how to do so if we do, we have had some useful discussions that have generated some new ideas and have helped us understand some issues in how we present such features.

New paper: N3589, Summary of Progress Since Portland towards Transactional Language Constructs

By Blog Staff | Mar 16, 2013 03:44 PM | 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: N3589

Date: 2013-03-15

Summary of Progress Since Portland towards Transactional Language Constructs for C++

by Hans Boehm, Justin Gottschlich, Victor Luchangco, Maged Michael, Mark Moir, Torvald Riegel, Michael Scott, Michael Spear, Tatiana Shpeisman, Michael Wong

Excerpt:

We restrict attention in this document to issues that we have agreed upon for the next version of the specification, which we are preparing. Other accompanying documents are:

  • Draft Specification of Transactional Language Constructs for C++(v1.1) [1]
  • Summary of discussions on explicit cancellation (N3591) [2]
  • Alternative proposal for cancellation and exceptions (N3592) [3]

New paper: N3564, Resumable Functions -- Niklas Gustafsson et al.

By Blog Staff | Mar 15, 2013 04:44 PM | 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: N3564

Date: 2013-02-15

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 N3558. 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 paper: N3558, A Standardized Representation of Async Operations -- Niklas Gustafsson et al.

By Blog Staff | Mar 15, 2013 04:38 PM | 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: N3558

Date: 2013-03-15

A Standardized Representation of Asynchronous Operations

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.

... Target Audience:

  • Programmers wanting to write I/O and compute heavy applications in C++
  • Programmers who demand server side scalability, client side responsiveness, and non-blocking UI threads from applications
  • Programmers who rely on multiple asynchronous operations, each with its own completion event

New paper: N3554, A Parallel Algorithms Library -- NVIDIA, Microsoft, Intel

By Blog Staff | Mar 15, 2013 04:21 PM | 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.

Context: In Kona, Redmond, and Portland, Study Group 1 (SG1, Concurrency) discussed language- and library-based ways to add parallelization and vectorization to Standard C++. For Bristol, three participating companies -- NVIDIA, Microsoft, and Intel -- were asked to come up with a combined proposal for a parallel algorithms library as one contribution. This is their first combined paper.

Document number: N3554

Date: 2013-03-15

A Parallel Algorithms Library

by Jared Hoberock et al. (NVIDIA, Microsoft, Intel)

Excerpt:

1 Executive Summary

We introduce a library of algorithms with parallel execution semantics. Some of these algorithms have semantics similar to the existing standard library of sequential algorithms. Some of the algorithms we propose are novel.

We introduce three parallel execution policies for parallel algorithm execution: std::seq, std::par, and std::vec, as well as a facility for vendors to provide non-standard execution policies as extensions. These policy objects may be used to specify how a parallel algorithm should be executed:

std::vector<int> vec = ...

// legacy sequential sort
std::sort(vec.begin(), vec.end());

// explicit sequential sort
std::sort(std::seq, vec.begin(), vec.end());

// parallel sort
std::sort(std::par, vec.begin(), vec.end());

// vectorized sort
std::sort(std::vec, vec.begin(), vec.end());

// sort with dynamically-selected execution
size_t threshold = ...
std::execution_policy exec = std::seq;
if(vec.size() > threshold)
{
  exec = std::par;
}

std::sort(exec, vec.begin(), vec.end());

// parallel sort with non-standard implementation-provided execution policies:
std::sort(vectorize_in_this_thread, vec.begin(), vec.end());
std::sort(submit_to_my_thread_pool, vec.begin(), vec.end());
std::sort(execute_on_that_gpu, vec.begin(), vec.end());
std::sort(offload_to_my_fpga, vec.begin(), vec.end());
std::sort(send_this_computation_to_the_cloud, vec.begin(), vec.end());

Algorithms invoked with std::seq execute internally in sequential order in the calling thread.

Algorithms invoked with std::par are permitted to execute internally in an unordered fashion in unspecified threads. It is the caller’s responsibility to ensure that the invocation does not introduce data races or deadlocks.

Algorithms invoked with std::vec are permitted to execute internally in an unordered fashion in unspecified threads. In addition to the restrictions implied by std::par, it is the caller’s responsibility to ensure that a std::vec invocation does not throw exceptions or attempt to perform synchronization operations.

Algorithms invoked without an execution policy execute as if they were invoked with std::seq.

An implementation may provide additional execution policies besides std::seq, std::par, or std::vec.

This proposal is a pure addition to the existing C++ standard library; we do not believe it alters the semantics of any existing functionality.

2 Design Notes and Outstanding Questions

Before introducing the detailed specification of our proposal, we begin by outlining our rationale and by noting that we have identified a number of outstanding questions which require further work to resolve. ...