Articles & Books

The C++ Programming Language Fourth Edition is now shipping

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

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

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

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

Quick Q: How can I make my type construct from { 1, 2, 3, 4 } like vector? -- StackOverflow

Quick A: Write a constructor that takes a std::initializer_list.

See the link for the nice longer answer:

how to implement an initializer list for user defined type? (analogus to std::vector initializer list)

std::vector can be initialized as

 

std::vector<std::string> words1 {"the", "frogurt", "is", "also", "cursed"};
ref

Now if want to achieve the similar functionality for one of my types how do I go about doing it? How should I implement the constructor for this functionality?

Quick Q: How does return by rvalue reference work? -- StackOverflow

Quick A: So easily that it's automatic... just return a value, not a reference.

How does return by rvalue reference work?

Just when I thought I kind of understand rvalue reference, I ran into this problem. The code is probably unnecessarily long, but the idea is quite simple. There is a main() function, and returnRValueRef() function.

[...]

AClass && returnRValueRef() {
  AClass a1(4);
  return move(a1);
}

int main() {
  AClass a;
  a = returnRValueRef();
}

Quick Q: What's the difference between vector<T...> and vector<T>...? -- StackOverflow

SO's version of the question added one layer of wrapping:

What's the difference between doing vector<vector<T...>> and vector<vector<T>...>

I saw code like this earlier:

 

using A = std::vector<std::vector<T>...>

where T is a variadic list of template arguments. I wanted to know what the difference is between putting the parameter pack at the end of the last angle bracket and the first. For example:

using B = std::vector<std::vector<T...>>;

Both of these two compile fine but I don't know what the difference is.

Can someone explain? Thanks.