Home » Blog » Categories »

New paper: N3708, A proposal to add coroutines to the C++ standard library -- O Kowalke, N Goodspeed

By Blog Staff | Aug 28, 2013 02:28 PM | Tags: concurrency

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

Date: 2013-03-04

A proposal to add coroutines to the C++ standard library

by Oliver Kowalke and Nat Goodspeed

Excerpt:

This proposal suggests adding two first-class continuations to the C++ standard library:
std::coroutine<T>::pull_type and std::coroutine<T>::push_type.

A Glimpse into C++14: Combine Flexibility and Performance with Dynamic Arrays and... -- Danny Kalev

By Blog Staff | Aug 28, 2013 12:45 PM | Tags: basics

cpp14-target.jpgDanny Kalev wrote a nice article yesterday about a new C++ feature -- actually, two related C++14 features -- that were just added to the draft Standard in April and will be coming to real compilers in the near future.

A Glimpse into C++14: Combine Flexibility and Performance with Dynamic Arrays and Runtime-Sized Arrays

by Danny Kalev

From the article:

C99 introduced the notion of variable length arrays: stack allocated built-in arrays whose size is determined at runtime. C++ lacks a similar feature, to the discontent of many a programmer. However, two recent proposals for adding dynamic arrays and runtime-sized arrays to C++14 are closing the gap at last. Learn how to use these new features to imitate C99’s variable length arrays in C++...

New paper: N3733, ISO/IEC CD 14882, C++ 2014, National Body Comments -- Barry Hedquist

By Blog Staff | Aug 28, 2013 12:37 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: N3733

Date: 2013-08-26

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

by Barry Hedquist, INCITS/PL22.16 IR

Excerpt:

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

This document is a revision to SC22 N4836, CD14882 Collated Comments. The revision contains a consistent numbering scheme for all comments. Comments that contained no numbering were numbered sequentially in the exact order presented in SC22 N4836. Comments that were numbered in the "Line Number" column (column 2) were moved to the MB/NC column (column 1). No other editing was done on any of the comments.

Document numbers referenced in the ballot comments are WG21 documents unless otherwise stated.

Optimizing C++ Code: Dead Code Elimination -- Jim Hogg

By Blog Staff | Aug 28, 2013 12:29 PM | Tags: intermediate

We keep hearing about C++'s "as if" rule, but what does it really do? Fundamentally, it enables optimizations. A modern compiler never produces an executable that's identical to the program you actually wrote; it produces an equivalent program that's probably a lot better.

Hence Jim Hogg's nice new series on what optimizing compilers do, using Visual C++ as an example. The latest instalment:

Optimizing C++ Code : Dead Code Elimination

by Jim Hogg

From the article:

This post examines the optimization called Dead-Code-Elimination, which I’ll abbreviate to DCE.  It does what it says: discards any calculations whose results are not actually used by the program.

Now, you will probably assert that your code calculates only results that are used, and never any results that are not used: only an idiot, after all, would gratuitously add useless code -- calculating the first 1000 digits of pi, for example, whilst also doing something useful.  So when would the DCE optimization ever have an effect? ...

C++: Polymorphic Cloning and the CRTP (Curiously Recurring Template Pattern)--Katy Coe

By matt | Aug 23, 2013 06:06 AM | Tags: polymorphism intermediate crtp cloning c++11

katy.pngOn CRTP with multi-level inheritance, cloning, and the constructor forwarding problem.

C++: Polymorphic cloning and the CRTP (Curiously Recurring Template Pattern)

by Katy Coe

From the article:

A common problem in C++ occurs when you have an object of an unknown derived type and want to make a copy of it. ...

The solution is to use the commonly-used polymorphic cloning pattern. In this pattern, we define a virtual function -- which we’ll call clone() in this article -- which when called via an object pointer returns a new object of the correct derived type.

Continue reading...

XL C/C++ V11.1 supports extern templates, enum class, right angle brackets -- IBM C/C++ Cafe

By Cecilia | Aug 20, 2013 09:06 PM | Tags: None

[Ed.: We're pleased to report continued progress toward conformance by C++ compiler vendors. This post combines three features contributed by Cecilia, christineli, and Alice Ying]

The IBM XL C/C++ V11.1 now supports several new C++11 features.

With extern templates, you can provide an explicit instantiation declaration for a template specialization if an explicit instantiation definition of the template exists in other translation units or later in the same file. If one translation unit contains the explicit instantiation definition, other translation units can use the specialization without having the specialization instantiated multiple times.

With right angle brackets, you can avoid having to write an extra space in code like vector<list<int> >, and just write vector<list<int>> the way Stroustrup intended. 

With scoped enumerations, you can avoid the following problems with the traditional enumerations:

  • Implicit conversion to an integer
  • Inability to specify the underlying type
  • Scope issue: enumerator is injected into (a.k.a. "pollutes") the enclosing scope

Enjoy!

noexcept Destructors -- Andrzej KrzemieĊ„ski

By Blog Staff | Aug 20, 2013 06:03 PM | Tags: intermediate

A slight change from C++98 to C++11, tightening up destructor semantics. Yes, it's still considered a best practice to never allow an exception to escape from a destructor -- in any language with destructor or Dispose functionality -- and now we have an additional reason in C++11:

noexcept Destructors

by Andrzej Krzemieński

From the article:

The goal of this post is to show one — fairly small — backwards incompatibility in C++11. It shows how noexcept exception specifications are implicitly generated for your destructors. In short, the following program used to run successfully in C++03 (under some definition of “success”): ...

In this post I do not intend to argue whether it is a bad practice or not to throw from destructors, but focus on what happens when you do. But I really do not encourage you to throw from destructors...