Home » Blog » Categories »

New paper: N3690, Programming Languages -- C++, Committee Draft

By Blog Staff | May 15, 2013 07:12 PM | Tags: None

Note: This updated working draft contains all of the updates approved at the Bristol ISO C++ meeting to make this the C++14 Committee Draft. Today our project editor Stefanus Du Toit, wth the kind help of Jonathan Wakely and our editorial committee of Daniel Kruegler, Alisdair Meredith, Mike Miller, and Richard Smith, finished applying and verifying the updates voted in at Bristol. This document has now been transmitted to SC22 for circulation for C++14's primary international comment ballot.

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

Date: 2013-05-15

Programming Languages -- C++, Committee Draft

Thanks once again to the over 100 people who attended the Bristol meeting, and several hundred more who helped work on reaching this C++14 feature-complete milestone!

Once the ballot has completed, the next step will be to consider and address all of the national body comments, and then circulate an updated Draft International Standard (DIS) for its possibly-final ballot one level higher in ISO/IEC JTC1. For more information about the standards process and stages, please see Standardization | ISO/IEC JTC1 Procedures.

C++Now presentations appearing on GitHub

By Blog Staff | May 15, 2013 05:23 PM | Tags: None

The C++Now 2013 conference is still in flight, but presentation materials are being made available online as the conference progresses. You can find them here in their GitHub repository:

C++Now 2013 Presentations (GitHub)

Some of the highlights posted so far include:

Keynote: Optimizing the Emergent Structures of C++ (Chandler Carruth)

Library in a Week: C++11 & Boost Cookbook (I) (Jeff Garland)

Survey of Multi-Threaded Programming Support in C++11 and Boost (Rob Stewart)

A Zephyr Overview of C++11 (Leor Zolman)

A First Look at Proto-0x (Eric Niebler)

See the repo for much more...

The C++ Programming Language Fourth Edition is now shipping

By Bjarne Stroustrup | May 13, 2013 10:27 AM | Tags: None

My book The C++ Programming Language (Fourth Edition) is now shipping.

I got my copy (the very first copy!) on Friday. At 9am Monday, it became available on the publisher’s site, InformIT, and at 10am it had sold out. This is all very scary for an author. I have worked hard on this for about four years (not counting the 13 years it took getting the C++11 standard out), but of course a 1360-page book is huge, so I’ll find flaws. Anyway, that’s my problem.

For a description of the book, see http://www.stroustrup.com/4th.html. In particular, read the preface and the back-cover text to see if this book might be of interest to you. It aims to be the most comprehensive description of the C++ language, standard library, and the programming techniques C++ is designed to support. It is not meant to be the quickest introduction to C++11 or a first introduction to programming. My TC++PL4 web page also has an extended table of contents, the Tour of C++, and the exercises.

As ever, comments (preferably polite and constructive) and bug reports are most welcome.

GotW #2 Solution: Temporary Objects -- Herb Sutter

By Blog Staff | May 13, 2013 05:27 AM | Tags: intermediate basics

The solution to GotW #2 is now available:

GotW #2 Solution: Temporary Objects (updated for C++11/14)

by Herb Sutter

From the article:

Because C++ naturally enables move semantics for returned values like this string object, there’s usually little to be gained by trying to avoid the temporary when you return by value. ... For example, if the caller writes auto address = find_addr( mylist, “Marvin the Robot” );, there will be at most a cheap move (not a deep copy) of the returned temporary into address, and compilers are allowed to optimize away even that cheap move and construct the result into address directly.

But what if you did feel tempted to try to avoid a temporary in all return cases by returning a string& instead of string? Here’s one way you might try doing it that avoids the pitfall of returning a dangling reference to a local or temporary object: [...] To demonstrate why this is brittle, here’s an extra question:

For the above function, write the documentation for how long the returned reference is valid.

Go ahead, we’ll wait. ...

The questions for #3 are posted for discussion:

GotW #3: Using the Standard Library (or, Temporaries Revisited)

 

 

Some Subtleties of Aliasing -- Andrew Koenig

By Blog Staff | May 12, 2013 04:59 PM | Tags: intermediate

Why "aliasing can cause paradoxical behavior"...

Some Subtleties of Aliasing

by Andrew Koenig

 

... As an example of a problem with this code, I suggested that it might be called by writing

 

scale(v, v[n]);

with the aim of dividing every element of v by v[n], but that this call would actually do something else entirely. From the comments on the article, I think that some readers were unclear about what that something else might be. To understand this call's behavior in detail, we have to look at the code more closely. ...

Quick Q: What's the best way to return multiple values? -- StackOverflow

By Blog Staff | May 12, 2013 01:55 PM | Tags: basics

Another example of how adding a feature, in this case move semantics, makes using the language simpler:

Interface for returning a bunch of values

I have a function that takes a number and returns up to that many things (say, ints). What's the cleanest interface?

  1. Return a vector<int>. The vector would be copied several times, which is inefficient.
  2. Return a vector<int>*. My getter now has to allocate the vector itself, as well as the elements. There are all the usual problems of who has to free the vector, the fact that you can't allocate once and use the same storage for many different calls to the getter, etc. This is why STL algorithms typically avoid allocating memory, instead wanting it passed in.
  3. Return a unique_ptr<vector<int>>. It's now clear who deletes it, but we still have the other problems.
  4. Take a vector<int> as a reference parameter. The getter can push_back() and the caller can decide whether to reserve() the space. However, what should the getter do if the passed-in vector is non-empty? Append? Overwrite by clearing it first? Assert that it's empty? It would be nice if the signature of the function allowed only a single interpretation.
  5. Pass a begin and end iterator. Now we need to return the number of items actually written (which might be smaller than desired), and the caller needs to be careful not to access items that were never written to.
  6. Have the getter take an iterator, and the caller can pass an insert_iterator.
  7. Give up and just pass a char *. smile