N4035: Implicit Evaluation of auto Variables and Arguments -- J Falcou, P Gottschling, H Sutter

By Blog Staff | May 23, 2014 08:35 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: N4035

Date: 2014-05-23

Implicit Evaluation of auto Variables and Arguments (revision 1)

by Joel Falcou, Peter Gottschling, Herb Sutter

Excerpt:

Revision to N3748

1. Prioritized syntax changed.

2. Third alternative introduced.

3. Library-based disabling introduced.

4. Some type traits removed.

Altogether, the proposal is a clear simplication to its predecessor.

1 Motivation

Type detection for variables from expressions' return type:

auto x= expr;

has proven high usability. However, it fails to meet most users' expectations and preferences when
proxies or expression templates (ET) are involved, e.g.:

matrix A, B;
// setup A and B
auto C= A  B;

Many people would expect C to be of type matrix as well. Whether C is a matrix depends on the
implementation of operator*. ...

N4009: Uniform Container Erasure -- Stephan T. Lavavej

By Blog Staff | May 22, 2014 03:23 PM | Tags: None

[Ed.: Alternative title: "Finally! Let's please erase and remove the erase-remove idiom"...]

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

Date: 2014-05-22

Uniform Container Erasure

by Stephan T. Lavavej

Excerpt:

This is a proposal to add erase_if(container, pred), making it easier to eliminate unwanted elements correctly and efficiently.

II. The Problem

It's surprisingly difficult to eliminate unwanted elements from a container, given a predicate that distinguishes "bad" elements from "good" elements. ...

N3994: Range-Based For-Loops: The Next Generation (Revision 1) -- Stephan T. Lavavej

By Blog Staff | May 22, 2014 03: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.

Document number: N3994

Date: 2014-05-22

Range-Based For-Loops: The Next Generation (Revision 1)

by Stephan T. Lavavej

Excerpt:

This updates N3853 (see [1]) which proposed the syntax "for (elem : range)", by adding support for attributes and answering additional questions. Please see the original proposal for the rationale behind this feature, which is not repeated here.

...

Q15. Has this been implemented?

A15. Yes!  David Vandevoorde and Jonathan Caves have reported that they were
able to implement N3853 in less than an hour each. ...

N3977: Resumable Functions -- Niklas Gustafsson

By Blog Staff | May 22, 2014 03:10 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: N3977

Date: 2014-05-22

Resumable Functions

by Niklas Gustafsson

Excerpt:

This document is directly related to N3970, the working draft for a Technical Specification focusing on concurrency. It proposes a number of additions to N3970.

In relation to the superseded document N3858, this paper drops all the background information and focuses on proposed edits to the Concurrency TS. For background information, the reader is referred to the superseded document.

It is hereby proposed that the following modifications to the standard be incorporated into the Concurrency Technical Specification, N3970. Section and paragraph numbers refer to the C++ standard working draft.

N4023: Working Draft, C++ Extensions for Library Fundamentals -- Jeffrey Yasskin

By Blog Staff | May 22, 2014 12:49 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: N4023

Date: 2014-05-21

Working Draft, C++ Extensions for Library Fundamentals

by Jeffrey Yasskin

Excerpt:

This technical specification describes extensions to the C++ Standard Library (1.2). These extensions are classes and functions that are likely to be used widely within a program and/or on the interface boundaries between libraries written by different organizations. ...

The goal of this technical specification is to build more widespread existing practice for an expanded C++ standard library. It gives advice on extensions to those vendors who wish to provide them.

Quick Q: Why can't a data member be in a lamba capture list -- StackOverflow

By Blog Staff | May 22, 2014 12:01 PM | Tags: basics

Quick A: Because you can only capture local (stack) objects, including function parameters, and to access a data member in a member function you capture the local variable this.

Today on SO:

Why can't a data member be in a lamba capture list

I have a class foo that has bar as a member variable.

In another member function of the class, I'm writing a lambda function:

[bar](void){}

But I can't include bar in the capture list. Why is that?

N3976: Multidimensional bounds, index and array_view, revision 2 -- Łukasz Mendakiewicz, Herb Sutter

By Blog Staff | May 22, 2014 09: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: N3976

Date: 2014-05-21

Multidimensional bounds, index and array_view, revision 2

by Łukasz Mendakiewicz and Herb Sutter

Excerpt:

The feedback we have received during the Issaquah meeting was to prepare the wording for the proposal as-is. Consequently, only the wording (with minor improvements) is provided in this version. Interested readers should find the rationale, background information and design discussion in the previous revision of the proposal, viz. N3851.

C++Now 2014 talk slides now available

By Blog Staff | May 22, 2014 09:06 AM | Tags: None

Many of the slides from last week's sold-out C++Now event are now posted on GitHub at the link below, and more are still being added.

If you missed C++Now this year, head over to check out the new CppCon coming this September...

C++Now 2014 Presentations

Tuesday, May 13

Library in a Week - c++ templating engine

Keynote: Axiomatic Programming: From Euclidean Deductions to C++ Templates and Beyond

C++14: Through the Looking Glass

Coroutines, Fibers, and Threads, Oh My

The Canonical Class

ConceptClang: Theoretical Advances with Full C++ Concepts

Generic Programming of Generic Spaces: Compile-Time Geometric Algebra with C++11

Test-Driven Development With Boost.Test and Turtle Mock, Part I/II

Removing undefined behavior from integer operations: the bounded::integer library

Value Semantics and Range Algorithms - Composability and Efficiency

Preparing the C++11 Library AFIO for Boost Peer Review

Wednesday, May 14

MPL11: A New Metaprogramming Library for C++11

The Optimization of a Boost.Asio-Based Networking Server

Undefined Behavior in C++; what is it, and why should I care

Mach7: The Design and Evolution of a Pattern Matching Library for C++

Practical Type Erasure: A boost::any Based Configuration Framework

A Tutorial Introduction to C++11/14 Part I/II

C++11 in Space Plasma Model Development

C++11 Library Design

Goals for Better Code: Implement Complete Types

Multiplatform C++

Octopus: A Policy-Driven Framework for CFD Simulations

Thursday, May 15

Keynote: Beware of C++

Interactive Metaprogramming Shell Based on Clang

libcppa: Type-safe Messaging Systems in C++

Unicode in C++

CppComponents: A Modern Portable C++11 Component System

UI. Aesthetics. C++

Accelerator Programming with C++ AMP

Designing XML API for Modern C++

Modern C++ as Concurrent Assembly

Understanding &&

Boost Library Incubator | Zip Archive

Friday, May 16

Iterators May Stay | LibreOffice File

Value Semantics: It ain't about the syntax!

Create Your Own Refactoring Tool with Clang

How to Design C++ Implementations of Complex Combinatorial Algorithms

Intro to Functional Programming in C++

Managing Object Lifetimes

0xBADC0DE

Expected — An Exception-friendly Error Monad

Lifetime and Usage of Global, Thread-local, and Static Data

Functional Data Structures in C++

Asynchronous Programming Using Boost.MetaStateMachine and the Upcoming Asynchronous Library

Ownership of Memory in C++

Saturday, May 17

The Future of Accelerator Programming in C++

Functional Reactive Programming - Cleanly Abstracted Interactivity

Disambiguation: The Black Technology

My Thoughts on Large Code Base Change Ripple Management in C++

Future of Boost: Boostache

Future of Boost: Community Management Team

N3975: URI - Proposed Wording (Revision 5) -- Glyn Matthews and Dean Michael Berris

By Blog Staff | May 22, 2014 07:58 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: N3975

Date: 2014-05-22

URI - Proposed Wording (Revision 5)

by Glyn Matthews and Dean Michael Berris

Excerpt:

Revisions to N3947

1. Numerous updates to wording and style to make it more compatible with the standard document.
2. Removed string_type member typedef for the uri class.
3. Improved specification of the definition of port [uri.definition.port].
4. Updated [uri.requirements] to be the same as the filesystem proposal.
5. Renamed uri_error_code to uri_errc [class.uri_errc].
6. Added an additional sentence in [uri.scope] to describe the uri_errc enum.
7. Made member functions constexpr and noexcept, where appropriate.
8. Improved specification of equality and comparison operators [uri.header-synopsis.equality-comparison].
9. Added a section describing uri encoding conversions [class.uri.conversions]
10. Added some sentences on make_error_code, make_error_condition and uri_category [uri.header-synopsis.error-handling].
11. Updated uri_builder.
12. Improved specification for to_uri and to_filesystem_path to handle the case where the URI or filesystem path is relative [uri.header-synopsis.filesystem-interop].

Vector of Objects vs Vector of Pointers Updated -- Bartlomiej Filipek

By Blog Staff | May 22, 2014 07:30 AM | Tags: performance memory intermediate efficiency

More in the "contiguous enables fast" department:

Vector of Objects vs Vector of Pointers Updated

by Bartlomiej Filipek

From the article:

For 1000 particles we need on the average 2000 cache line reads! This is 78% more cache line reads than the first case! Additionally Hardware Prefetcher cannot figure out the pattern -- it is random -- so there will be a lot of cache misses and stalls.

In our experiment the pointer code for 80k of particles was more 266% slower than the continuous case.