The Future Is Here: C++11 -- Bjarne Stroustrup
Prof. Stroustrup spoke at A9 last week on "The Future is Here: C++11." The video is now available on YouTube:
The Future Is Here: C++11
Special Guest Lecture by C++ Inventor Bjarne Stroustrup
News
A Glimpse into C++14: Combine Flexibility and Performance with Dynamic Arrays and... -- Danny Kalev
Danny 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++...
Optimizing C++ Code: Dead Code Elimination -- Jim Hogg
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? ...
Inherited Constructors in C++11 -- Marius Bancila
A nice piece of writing on a C++11 feature:
Inherited Constructors in C++11
by Marius Bancila
From the article:
In C++, a function in a derived class with the same name as one (or a set of overloads) in a base class, hides the function (or the overloads) from the base class. Here is an example...
The Synchronizes-With Relation -- Jeff Preshing
Here is a nicely accessible description of synchronization in the C++ memory model:
The Synchronizes-With Relation
by Jeff Preshing
See also Jeff's other recent related posts:
C++: Polymorphic Cloning and the CRTP (Curiously Recurring Template Pattern)--Katy Coe
On 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.
Moving Data and Address Arithmetic -- Andrew Koenig
Today on Dr. Dobb's:
Moving Data and Address Arithmetic
by Andrew Koenig
From the article:
Programs that don't care about the addresses of their data rarely need to move those data. After all, we can view the whole point of moving an object as a way of changing the object's address without changing its contents...
XL C/C++ V11.1 supports extern templates, enum class, right angle brackets -- IBM C/C++ Cafe
[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
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
noexceptexception 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...
GotW #7a Solution: Minimizing Compile-Time Dependencies, Part 1—Herb Sutter
The solution to the latest GotW problem is now available. In this Item, the focus is on analyzing and managing compile-time dependencies.
GotW #7a Solution: Minimizing Compile-Time Dependencies, Part 1
by Herb Sutter
From the article:
Managing dependencies well is an essential part of writing solid code. C++ supports two powerful methods of abstraction: object-oriented programming and generic programming. Both of these are fundamentally tools to help manage dependencies, and therefore manage complexity. It’s telling that all of the common OO/generic buzzwords—including encapsulation, polymorphism, and type independence—along with most design patterns, are really about describing ways to manage complexity within a software system by managing the code’s interdependencies.
When we talk about dependencies, we usually think of run-time dependencies like class interactions. In this Item, we will focus instead on how to analyze and manage compile-time dependencies. As a first step, try to identify (and root out) unnecessary headers.
Guideline: Never #include unnecessary header files.
Guideline: Prefer to #include <iosfwd> when a forward declaration of a stream will suffice.
Guideline: Never #include a header when a forward declaration will suffice.