C++ Rocks!

JetBrains CLion C++ IDE First Impressions

Thu, 11 Sep 2014 00:00:00 +0000

This post describes my first impressions from taking the new JetBrains CLion C++ IDE (currently in alpha) for a spin.

I’ve been a loyal user of another IDE made by JetBrains - RubyMine, which I’ve been using for Ruby on Rails and Node.js projects. This IDE is one of the best that I’ve used, so I was excited to hear about the public release of an alpha version of their C++ IDE.

It was particularly interesting to me as I mostly use a Mac but I haven’t looked at using XCode for C++ projects, so getting a familiar-feeling IDE on a Mac would be great.

What do I want from an IDE?

There are a few things I want from an IDE, and that’s what I look for every time I try out a new IDE.

It needs to have a good customizable editor (colors, fonts and code formatting).
It needs to have good code completion, and ideally interactive error notifications (e.g. with squiggly lines).
It needs to have easy project navigation, which includes switching between files, and context sensitive navigation (e.g. switching between declaration/definition or header/implementation).
Finally, it needs to have a fast debugger which makes it easy to view program state. I hold up Visual Studio’s example as the best example of that.

Getting Started with CLion

CLion works on Windows, Linux and Mac which is quite convenient for multi-platform projects.

The install went fine, I created a new project and CLion set up a minimal file structure. I added some code to main.cpp, and was able to get it compiled and running after adding a line to CMakeLists.txt (see Builds section below).

I also downloaded the source of the C++14 Streams library (https://github.com/jscheiny/Streams) which has a CMake build script. I was able to simply open its directory from CLion, hit Build and then Run, and had the tests run successfully without any hassle.

So that was a good start.

The Editor

Normally the first thing I do with a new piece of software is go into Settings and see what I can customize. CLion is built on top of the IntelliJ platform, so it has a massive set of configuration options (and I think an IDE can never have enough options so this is a good thing).

I could configure formatting options, folding options, tab behavior, code completion and shortcuts. There are predefined keymaps matching other software, including Visual Studio, XCode and Emacs. There is fine grained configuration of syntax highlighting, but font selection appears to be disabled at this point.

UPDATE: Font selection actually works fine, I just got confused. A nice thing with fonts is that CLion also lets me adjust line spacing (I like 1.2).

The list of code formatting options is insanely detailed:

There are tons of settings for spaces (do you want spaces specifically within array index braces?), wrapping and braces (do you want to align function parameters on multiple lines?), and for blank lines (do you want N blank lines after the includes?). I could configure the placement of braces for lambdas differently from everything else, which was very nice.

The display of templates initially confused me a bit:

Turns out, this is just an aspect of code folding. Template declarations are folded by default and can be expanded easily:

It would be good if the editor evaluated macros and greyed out any code that isn’t going to get compiled (the way Visual Studio does). That doesn’t seem to be implemented though:

Code Completion and Interactive Feedback

Support for some C++11 features isn’t implemented yet. This includes user defined literals, constexpr and enum class.

I noticed the squiggly line error highlights in the editor being incorrect for some other things (e.g. a declaration using decltype) while the code compiled and ran just fine. Other issues included an unused macro warning even though it was used several lines down in the file, as well as unwarranted complaints about lambda return type. Hopefully these are just alpha issues and will get fixed.

An interesting feature is parameter placeholders in function calls inserted via code completion:

The whole placeholder is selected as soon as the cursor goes over it, and it can be typed over. This is quite helpful, although as you can see, placeholders can be really long as they include automatically generated type names.

Another feature is automatic addition of #includes based on what I’m typing. E.g. if I’m writing a function declaration and add a chrono::time_point parameter, a #include <chrono> statement is automatically added to the top of the file. I don’t think this feature is complete so I don’t want to bash it too much, but it didn’t work for me.

For one thing, it added includes outside the header guard. For another, it didn’t seem reliable and I couldn’t figure out when it does or doesn’t add an include. In any case, seeing as includes can cause significant issues with cycles and build times, I’m not sure this can be automated well, especially in a large project. But I’ll be happy if it is :)

CLion has an awesome feature: double-Shift pops up a project file search box. I just need to enter a few characters to get to any file in the project. It also shows a list of opened files sorted by recency, so to switch repeatedly between two files (e.g. .h and .cpp) all I need to press is double-Shift followed by Enter:

The result of this is that I don’t actually need file tabs. Luckily, CLion allows me to hide them altogether, so I get extra editor space! I also kept the project tree closed most of the time - it’s only needed if I don’t remember the name of the file at all.

There is also an alternative to the tree view in the form of a breadcrumb bar with file/directory dropdowns at each level. It allows adding new files too, but I was disappointed that I couldn’t find an option to create a corresponding .h or .cpp counterpart for an existing file.

The net result is that I can have most of the window dedicated to the editor, which is how I like to work:

Navigation in the editor seemed to work flawlessly in my short test. The IDE found the standard header locations and allowed me to go to declarations of standard types (vector) and standard functions (push_back). It also picked up the location of an external library from CMakeLists.txt and parsed that, so I could go to those declarations too. It all worked really fast.

Builds

The IDE supports both GCC and Clang. On Windows, this means using MinGW or Cygwin.

The documentation says that most C++11 features are supported at IDE level. Both libc++ and libstdc++ are supported but Boost isn’t fully supported.

Only CMake is supported as “project format” right now, although there are plans to expand that (e.g. support Makefiles, Autotools and Qt projects). CMake integration isn’t particuarly advanced either, for example, when files are copied in, CMakeLists.txt isn’t updated automatically. Additionally, multiple build targets aren’t supported either.

The IDE found my install of Clang, so it was easy to get going. I just needed to drop

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -stdlib=libc++")

into CMakeLists.txt to get C++11 code to compile, and that was it.

Program output goes into a pane in the IDE, which is handy.

Debugging

Debugging worked out of the box, but it should be noted that at this point it’s based on GDB, with LLDB integration planned for later.

There are popups showing variable values on hover, which I consider a must. However, they don’t work very well. For one thing, when hovering on an object, all I get is the variable name with a plus sign which I have to click:

I can’t imagine the circumstances when that’s useful. Why not expand it automatically?

The other problem is that the debugger doesn’t seem to have any knowledge of standard C++ types. I couldn’t even see the contents of std::string. For a vector, I got an expansive representation of all its internals - not at all what I was looking for, which was a simple list of its elements.

That said, the debugger has useful functionality: stack views per thread, watches, stepping over, into and out, and breakpoints. Conditional breakpoints are possible. A handy option is tracing when a breakpoint is reached.

Refactoring and Code Fixes

I just tried these features out but didn’t give them any kind of extensive testing. I’m lukewarm about refactoring features, with only Rename getting consistent use from me. Renaming worked quite well within a single file. For example, when renaming a class, CLion was also able to rename references to the class in comments.

In addition to manual refactoring operations, some refactorings are suggested automatically with a lightbulb icon popping up next to the current line in the editor. These include things like removing unnecessary parentheses and moving function definition out of class. They seemed to work fine.

In my experience, refactoring support often falls short when multiple files and more complex constructs are involved, so it remains to be seen how well CLion will hold up to more serious use.

Extras

The IDE has a lot of other helpful features which aren’t in my “minimal feature set for a useful IDE”.

It’s got excellent source control integration, with Git, SVN and even TFS support available.

It has configurable parametrized code templates.

The fact that the IDE is built on the IntelliJ platform means that there are many further customisations and plugins available for this IDE.

It also means that more than one language can be supported, which could be great, for example, if you have a mix of C++ and Lua, or C++ and Python in your project.

Conclusion

I think this is an extremely promising product. It’s got plenty of rough edges at the moment, but hey - it’s alpha. There are also many features which are working great.

The build process, code analysis and debugging still need a lot of work, but the editor is already great.

I know that JetBrains makes excellent IDEs so I have high hopes for CLion.

Clang edition of the C++11/14 Rocks book

Tue, 29 Jul 2014 00:00:00 +0000

Do you use Clang to compile C++? Would you like to know all about the C++11 and C++14 language features it supports?

You can read about them in the new edition of my C++11/14 Rocks book tailored to Clang. I carefully collected everything you need into one short, clear book.

Clang already supports all of these C++14 features as of version 3.4:

Return type deduction for regular functions
Generic lambdas
Initialized lambda captures
Variable templates
Relaxed requirements on constexpr functions
Refined member initialization in aggregates
Binary literals
deprecated attribute
Single quotation mark as digit separator

Get C++11/14 Rocks - Clang edition

A couple of notes:

For those who have the GCC edition of the book: you’ll already be familiar with all the C++11 content as GCC also has full C++11 support. However, the Clang edition has full C++14 coverage instead of an overview.
The book doesn’t cover library features.

Spotlight on libraries relying on C++14

Mon, 21 Jul 2014 00:00:00 +0000

While working on the C++14 coverage for the Clang edition of my book, I’m also taking a look at the C++14 code in the wild, and I thought I’d write up what I’ve found.

There are, of course, implementations of the C++ standard library which by necessity rely on C++14 features. libc++ is complete with regards to C++14, and libstdc++ & Microsoft’s implementation have implemented the changes partially at this stage.

There aren’t many other libraries available at this point in time, but I did find a few. A lot of them aren’t fit for production use as yet, but it’s worth reading the code to see how people use C++14.

I included some code samples from the documentation but bear in mind that I haven’t actually used these libraries, so I don’t know how well they function in practice.

If you use Clang, you should have no problem compiling the libraries. GCC 4.9 may also work. Check out this post for a comparison of C++14 support across compilers.

Streams

Streams is a header-only C++14 library for functional style transformations and lazy evaluation. It allows you to do things like this:

int heads = stream::MakeStream::coin_flips() // Uniform random bools
    .limit(1000) // Take the first 1000 coin flips
    .filter()    // Take only the true ones (heads)
    .count();

It also provides set and vector operations:

std::set<Gadget> left = /* ... */
std::set<Gadget> right = /* ... */

std::set<Gadget> result =
    Stream<Gadget>(left).intersect_with(Stream<Gadget>(right))
    .to_set();

std::vector<double> vec1 = /* ... */
std::vector<double> vec2 = /* ... */;

auto stream = [](auto& x) {
    return stream::MakeStream::from(x);
};

auto sum = (stream(vec1) + stream(vec2)).to_vector();
auto scale = (stream(vec1) * 5).to_vector();
auto translate = (stream(vec1) + 10).to_vector();
int dot_product = (stream(vec1) * stream(vec2)).sum();

Sprout

This is a compile-time library which implements constexpr containers and algorithms.

It allows you to do things like this:

SPROUT_STATIC_CONSTEXPR auto input = sprout::array<int, 10>{ {1, 2, 3, 4, 5, 6, 7, 8, 9, 10} };

// count odd elements
SPROUT_STATIC_CONSTEXPR auto result = sprout::count_if(begin(input), end(input), bind2nd(modulus<>(), 2));
static_assert(result == 5, "counted 5 elements of odd number from input.");

// find min and max elements
SPROUT_STATIC_CONSTEXPR auto result = sprout::minmax_element(begin(input), end(input));
static_assert(*result.first == 1, "min element is 1.");
static_assert(*result.second == 10, "max element is 10.");

It also implements compile-time strings:

#include <sprout/string.hpp>
using namespace sprout;

SPROUT_STATIC_CONSTEXPR auto x = to_string("hello ");
SPROUT_STATIC_CONSTEXPR auto y = to_string("world");
SPROUT_STATIC_CONSTEXPR auto z = x + y;
static_assert(z == "hello world", "Should be: hello world.");

Mettle

Mettle is a unit testing library which uses C++14’s generic lambdas for test cases.

Here is an example from its documentation:

#include <mettle.hpp>
using namespace mettle;

suite<> basic("a basic suite", [](auto &_) {

    _.test("a test", []() {
        expect(true, equal_to(true));
    });

    _.skip_test("a skipped test", []() {
        expect(3, any(1, 2, 4));
    });

    for(int i = 0; i < 4; i++) {
        _.test("test number " + std::to_string(i), [i]() {
           expect(i % 2, less(2));
        });
    }

});

JeayeSON

JeayeSON is a header-only library for reading, writing and interacting with JSON with a typesafe C++14 interface. Here is an example from its readme:

/* To start with, create a map and load a file. */
json_map map{ json_file{ "src/tests/json/main.json" } };

/* We can look at some specify top-level values with "get".
     Notice that "get" returns a reference to the object. */
std::string &str(map.get<std::string>("str")); // Get "str" as a mutable string reference.
std::cout << "str = " << str << std::endl;
auto &arr(map.get<json_array>("arr"));

/* A fallback value can also be specified with "get". It does two things:
       1. Helps deduce the type so that an explicit invocation is not needed
       2. Provides a default fallback value, should anything go wrong while accessing
     Note that these functions do NOT return references, due to incompatibilities with the fallback. */
std::string const str_copy{ map.get("str", "Default awesomeness") }; // Second param is the default

/* Delving into maps using dot-notated paths works, too.
     The type can be explicitly specified, or implicit based on the provided fallback.
     They default to json_value, which offers op==, op<<, et cetera. */
std::cout << map.get_for_path("person.name") << " has " // No fallback, returns json_value&
          << map.get_for_path("person.inventory.coins", 0) << " coins\n"; // Fallback is 0

/* A less verbose way is to just use op[] on the json_values; this is more convenient,
   * but it comes at the cost of less type-safety and more runtime checks. */
std::cout << map["person"]["inventory"]["coins"] << std::endl;
std::cout << map["arr"][1] << std::endl;

/* Iterators work as expected, based on the C++ stdlib. (const and non-const) */
for(auto const &it : arr) { std::cout << it.as<json_float>() << " "; }
std::cout << std::endl;

jbson

jbson is a header-only library for building & iterating BSON data, and JSON documents in C++14. It also parses MongoDB extended JSON.

Here is what it looks like:

// building a document
using namespace jbson;
auto str = "str"s;
int num = 123;

document doc = builder
    ("some string", str)
    ("some int", num)
    ("some obj", builder
        ("child bool", false)
    );

// parsing JSON
using jbson::literal;
auto doc = R"({
    "some json": 123
})"_json_doc;

// iteration
for_each(doc.begin(), doc.end(), [](auto&& v) { something(v); });

FP

This is a C++14 header-only arithmetic library. It provides a couple of template wrappers for numeric types.

The first template, fp, provides fixed point arithmetic support:

fp<int, 4> x = 3.25;
fp<char, 8> y = 0.75;

auto z = x * y;
//now z is of type fp<int, 12>
std::cout << double(z);
//prints 2.4375

The second template, range, provide range checking for the wrapped type by implementing interval arithmetic at compile time:

auto test1 = ranged<int32_t, -20, 50>{ 10 };
auto test2 = ranged<int32_t, 1000, 10000>{ 2000 };
auto test3 = ranged<int32_t, -3000, 8000>{ 100 };
// the following will cause a compile error because the result 
// can be as big as 4'000'000'000, which is above MAX_INT:
auto test4 = test1 * test2 * test3;

auto test1 = ranged<int, -20, 50>{ 10 };
// the following assignment will cause a compile error 
// because test1 could have a value up to 50, 
// but test2 only accepts values up to 49:
ranged<int, -20, 49> test2 = test1;

Polyop

The goal of this library is to provide a universal mechanism for operator overloading (including built-in operators) with no runtime overhead. It also allows partial operator application and storing operator expressions for later evaluation.

Here is an example:

int a = 1, b = 2;

auto comp = pop::wrap(a) == b; // The comparison is not executed but stored in comp.
bool r1 = comp(); // Call the comparison.
auto expression = __ == __;          // Store a naked comparison expression
auto partial_call = expression(a); // Pass the first argumment to the expression
bool r2 = partial_call(b);         // Pass the last argumment to the expression (Then calling the operator).

bool lex_result = (pop::wrap(a) == b).context(lexicographical); // Applies a "lexicographical" comparison context.

Video++

Video++ “is a video and image processing library that takes advantage of the C++11 and C++14 standard to ease the writing of fast parallel real-time video and image processing.”

This is a sample from its documentation:

// A parallel implementation of a box_filter using Video++.

image2d<int> A(1000, 1000);
image2d<int> B(A.domain());

auto nbh = box_nbh2d<int, 3, 3>(A);

// Parallel Loop over pixels of in and out.
pixel_wise(A, B) << [&] (int& a, int& b) {
    int sum = int;

    // Loop over neighbors wrt nbh to compute a sum.
    nbh(a) < [&] (int& n) sum += n;

    // Write the sum to the output image.
    b = (sum / 3);
};

One of the features it provides is compatibility with with OpenCV image types:

// Load JPG image in a vpp image using OpenCV imread.
image2d<vuchar3> img = from_opencv<vuchar3>(cv::imread("image.jpg"));

// Write a vpp image using OpenCV imwrite.
cv::imwrite("in.jpg", to_opencv(img));

iod

This library takes an interesting approach of providing a DSL for inline object definitions and declarations with static introspection for C++11/14. It allows you to define and instantiate a C++ object inline, with no runtime overhead. It also allows extending such objects as you’ll see in the example below.

One obvious downside is that all attribute names have to be declared beforehand:

// Declaration of the attributes used by the inline object definitions.
iod_define_attribute(name);
iod_define_attribute(age);
iod_define_attribute(cars);
iod_define_attribute(model);
iod_define_attribute(cities);
iod_define_attribute(lastname);

int main()
{
    // Inline object definition.
    auto person = iod(
        *name = "Philippe", // Stared fields are serialized.
        *age = 42,
        inc_age = [] (auto& self, int inc) { self.age += inc; }, // Requires C++14.
        *cities = {"Paris", "Toronto", "New York City"},
        *cars = {
            iod(*name = "Renault", model = "Clio"), // All elements of an array must have the same type.
            iod(*name = "Mercedes", model = "Class A")
        }
    );

    // Access to the content of the object.
    std::cout << person.name << std::endl;
    std::cout << person.cars[1].model << std::endl;

    // Serialize an object to json.
    std::string json = iod_to_json(person);
    std::cout << json << std::endl;

    // Extend and object. (todo)
    auto extended_person = iod_extend(person, iod(lastname = "Doe"));
}

formatstring

This is a C++14 type safe format string library heavily inspired by Python’s str.format() function:

// create a temp. formatting object that gets written to cout
std::cout << format("hex: {:#x}, centerd: {:_^20}, padded: {:+010.3f}\n",
                    1234, "test", 3.14159);

// create a temp. formatting object the gets converted into a string
std::string s1 = format("{:d} {:c}", 'A', 66);

// convert a single value to a string
std::string s2 = hex(1234).fill('0', 20).alt();

Hana

This library is an attempt to merge Boost.Fusion and the Boost.MPL into a single metaprogramming library. It carries an explicit disclaimer that it isn’t fit for production use, and it seems to be under active development.

It allows you to perform advanced compile time computation, for example:

BOOST_HANA_STATIC_ASSERT(
    zip_with(_ * _, list(1, 2, 3, 4), list(5, 6, 7, 8, "ignored"))
    ==
    list(5, 12, 21, 32)
);

cpp-react

This is a C++1y micro-framework for functional reactive programming.

cpp-blend

cpp-blend is another C++14 string formatting library which aims to be extensible and typesafe.

{{ bustache }} is a C++1y implementation of {{ mustache }}, a template language for text substitution.

bustache::format format{"{{ mustache }} templating"};
bustache::object data{ {"mustache", std::string("bustache")} };
std::cout << format(data); // prints "bustache templating"

ETL

ETL is a C++11/14 Embedded Template Library for AVR 8-bit microcontrollers which contains an implementation of a subset of STL.

MNMLSTC Core

Finally, I thought it’s worth mentioning MNMLSTC Core - a library which implements various proposals for C++14 and beyond in C++11. It’s useful if you want to start using C++14 features but don’t have a C++14 compliant compiler as yet.

This library includes the following (among a lot of other stuff):

variant<Ts...>
optional<T>
expected<T>
deep_ptr<T>
poly_ptr<T>
string_view
range<T>
any

That’s it for today!

What if C++ looked more like Python or CoffeeScript?

Fri, 09 May 2014 00:00:00 +0000

I’m quite fond of languages with minimal syntax. Not only it is easier to read and write code in these languages - it also provides an opportunity to reduce errors (both at compile time and at run time), when you consider that every character in a program has the potential to cause an error due to being misread or misplaced. In addition, long, dense lines of code littered with punctuation increase the cognitive burden on the programmer.

In this post, I would like to sketch out an idea for a modified C++ syntax with reduced noise. I don’t make claims about the practicality of implementing such syntax, and it’s by no means a complete solution. However, I thought that it’s an interesting thought experiment, and I’d enjoy a simpler syntax if it was available.

Another thing I should mention is that it isn’t meant to be a backward-compatible syntax change which could be incorporated into, say, C++17. What I’m exploring is a dialect of C++ with Python-like syntax but with most of C++ constructs and semantics intact.

The basic idea is very straightforward, and of course already applied in other languages. Remove semicolons and curly braces used to denote code blocks, make parentheses in control structures optional, make indentation significant (as in Python and CoffeeScript) - voila, less noise.

The code could look like this:

#include <iostream>
using namespace std

namespace utils
    template<typename T>
    auto square(const T& n)
        return n * n

int main()
    auto input = 0
    auto message = "Please enter a positive number"

    cout << message << ":" << endl
    cin >> input

    if input > 0
        cout << "Result: " << utils::square(10) << endl
    else
        cout << message << endl
    return 0

Generally speaking, the newline becomes the end of a statement, and indentation indicates a code block. Curly braces can still be used in initialization constructs.

Some statements (like template declarations) will still require multiple lines. This kind of syntax requires some constraints to be placed on how statements can be split across multiple lines, but I think these can align pretty well with existing good code style.

The rest of this post is about dealing with various details, e.g. where this syntax can be ambiguous.

Newline and semicolon as statement separators

Generally, end of the line means the end of a statement:

Point<int> x
Point<double> y
Point<double> pt = x + y

The semicolon can be repurposed to combine multiple statements on one line:

Point<int> x; Point<double> y
Point<double> pt = x + y

The semicolon continues to be used in the for loop, so it’s mostly unchanged:

sregex_token_iterator token_it(begin(input), end(input), regex, 1)

for (auto it = token_it; it != sregex_token_iterator(); ++it) 
    cout << *it << endl

Multiline statements

Some statements can’t practically fit on one line and need to be recognized as multiline. One example is templates:

template<typename T> 
struct Point
    T x, y

template<typename T>
auto square(const T& n)
    return n * n

The template keyword and type list must be followed by a class or function declaration on the subsequent line.

What about a function declaration which requires more than one line? For example the return type might need to go on a separate line:

template<typename T1, typename T2>
auto operator+ (const Point<T1>& lhs, const Point<T2>& rhs) ->
    Point<decltype(lhs.x + rhs.x)> 
{
    // ... implementation ...
}

This can be parsed by introducing a set of non-terminating symbols, i.e. symbols which can’t end a statement. The arrow can be one of those.

Sometimes it will also be necessary for function parameters or arguments to span multiple lines:

template<typename T1, typename T2>
auto operator+ (
    const Point<T1>& lhs, 
    const Point<T2>& rhs) ->
    Point<decltype(lhs.x + rhs.x)> 

    // ... implementation ...

This could be parsed in two ways: one is that the parser keeps concatenating lines until it finds the closing parenthesis; the other is that commas become part of the non-terminating symbol set, and the parser concatenates the next line as long as the current line ends in a comma. Arguments passed when calling a function can be treated in the same way.

Finally, what about multiline string literals? For example:

    // log entry regex
    R"(([A-Z][A-Z])(\d+) "  // Flight no. "ETA "
    "(\d+:\d+) "            // ETA
    "Actual "
    "(\d+:\d+))"            // Actual time

I think it should be OK to concatenate them just like it’s currently done in C++. Even though this could be interpreted as separate literals on subsequent lines, such an interpretation wouldn’t be of much use.

Optional parentheses in control structures

The parentheses in control structures are optional:

if input > 0
    cout << "Result: " << utils::square(10) << endl
else
    cout << message << endl

switch color 
    case WHITE: cout << "#fff"; break
    case GRAY: cout << "#c0c0c0"; break
    case BLACK: cout << "#000"; break
    default: throw runtime_error("Unrecognized color value")

for auto& elem : elements
    elem = square(elem)

try
    Autopilot autopilot
    auto engage_task = async(launch::async, &Autopilot::engage, autopilot)
    // ...
    engage_task.get();  // throws an exception 
catch const runtime_error& e
    cout << e.what() << endl

auto i = 0
do
    cout << "*"
    cout << "-"
while i++ < 10

The handling of the while in do-while is similar to how this is handled in normal C++:

do i++;
while (i < 10);

Sometimes the expressions have to be quite long:

while diagnostics_task.wait_for(seconds(0)) == future_status::timeout ||
    autopilot_task.wait_for(seconds(0)) == future_status::timeout ||
    controls_task.wait_for(seconds(0)) == future_status::timeout

    cout << "."
    this_thread::sleep_for(milliseconds(500))

cout << "System ready." << endl

There are two ways of handling this situation. The set of non-terminating symbols includes the operators, so lines will be concatenated as long as they end in operators.

Alternatively, the condition can be enclosed in parentheses, which provides the option of breaking it up freely, just like in normal C++:

while (diagnostics_task.wait_for(seconds(0)) == future_status::timeout 
      || autopilot_task.wait_for(seconds(0)) == future_status::timeout 
      || controls_task.wait_for(seconds(0))  == future_status::timeout)

    cout << "."
    this_thread::sleep_for(milliseconds(500))

Declarations vs definitions

Suppose we have a function declaration and a definition:

auto f(int n)
{}

auto g(int n);

After removing semicolons and braces they become ambiguous:

auto f(int n)    // declaration or definition?

auto g(int n)

A backslash can be used to distinguish a function with an empty body:

auto f(int n) \     // definition

auto g(int n)       // declaration

The only requirement is to have a blank line following the backslash as that will be considered the function body. One problem with the backslash is that using it this way conflicts with the currently existing translation rules, so perhaps another symbol is necessary. But in any case, the point is that I need some way of specifying an empty block instead of {}.

The same principle applies to classes:

class A \           // empty class

class B             // class declaration

Method access specifiers

There are two options of formatting access specifiers. The obvious one is to indent them to the same level as the rest of the class body:

class JetPlane : public Plane

    vector<Engine> _engines

    public:

    JetPlane(const string& model = "") : Plane(model) \

    auto require_service(const date_t& date) \

    protected:

    auto load_person(const Person& person) 
        _passengers.push_back(person)

However, the prevalent existing style appears to be to align access specifiers with the class specifiers, so this could be allowed a special case instead:

class JetPlane : public Plane
    vector<Engine> _engines

public:    
    JetPlane(const string& model = "") : Plane(model) \

    auto require_service(const date_t& date) \

protected:
    auto load_person(const Person& person) 
        _passengers.push_back(person)

Lambdas

A lot of the syntax can be translated in a straightforward manner. However, lambda expressions are one of the trickier cases. Let’s take an example:

template<typename Cont>
auto print(const Cont& cont)
    for_each(begin(cont), end(cont), 
        [] (auto elem) cout << elem << endl)

I’ve removed the braces around the body of the lambda given to for_each. There was actually a proposal to allow lambda body to be an expression which suggested introducing this kind of syntax into C++14, so this is possible to parse - subject to some restrictions.

However, lambda expressions can be a lot more complex than this, with multiple statements in the body and so on.

In a more complex scenario, lambda bodies could be demarcated via indentation:

// update the screens in an airplane cabin
for_each(cabins.begin(), cabins.end(), [=](auto& cabin) 
    for_each(cabin.seats().begin(), cabin.seats().end(),
        [=](auto& seat_screen)
            seat_screen.set_mode(mode)
            seat_screen.refresh()
    )
)

While we’re at it, here is another potentially problematic situation: a function taking two callbacks as arguments. I could pass two lambdas to it:

make_request([], [])

Note that an empty lambda is now reduced to the introducer. What if I want something more elaborate? For example:

make_request([] 
    cout << "Request successful" << endl
    , 
    [] 
        cout << "Request failed" << endl
)

If I try to use indentation for lambda bodies, it looks pretty ugly and confusing. Instead, it’s better to allow an unindented leading comma (this is the CoffeeScript solution):

make_request([] 
    cout << "Request successful" << endl
, [] 
    cout << "Request failed" << endl
)

What about a lambda which is defined and called immediately?

auto a = 10;
const auto const_val = [&] { return a; }();

After removing semicolons and braces, I get this:

auto a = A(10)
const auto const_val = [&] return a ()  // potentially ambiguous

This is potentially ambiguous, so the lambda needs to be wrapped in parentheses:

auto a = A(10)
const auto const_val = ([&] return a)()  // OK, the function call operator
                                         // is applied to the lambda

Standalone code blocks

Standalone code blocks are occasionally useful for scoping. But without curly braces, code blocks like this would merge into one:

auto test_log()
{
    {
        std::ifstream ifs(log_file_name_rotated.c_str());
        ASSERT_TRUE(stream.is_open());
    }

    {
        std::ifstream stream(log_file_name.c_str());
        ASSERT_TRUE(stream.is_open());
    }
}

Relying on indentation isn’t going to be enough here, I need to tell the parser that a new block started. A backslash on its own line can be used for that (with the same caveat as before - another character may be better):

auto test_log()
    \
        std::ifstream ifs(log_file_name_rotated.c_str())
        ASSERT_TRUE(stream.is_open())

    \
        std::ifstream stream(log_file_name.c_str())
        ASSERT_TRUE(stream.is_open())

Things I don’t know how to handle

One thing I don’t know how to handle is unnamed types:

struct
{
    int x;
    void print() const
    {
        cout << x; 
    }
} a;

I don’t see an easy way of delimiting the type definition from the variable without adding a new keyword or a symbol to mark an anonymous type. Personally, I’d be happy to live without anonymous types in exchange for the other benefits, but this may not be a good tradeoff for other people.

Syntactic constructs that wouldn’t work in C++

There are a few other constructs which are useful in other languages, so I considered them briefly, but decided they wouldn’t work or wouldn’t add much value in the C++ context.

Treating everything as an expression and optional returns

Another thing CoffeeScript and Ruby do is treating everything as an expression:

message = if lander_count > 10
    "Launching probe"
else
    "Waiting for probes to return"
end

Consequently, methods return the result of the last expression, and the return keyword is optional:

def can_land?
    landers.count > 0  # returns the result of evaluating expression
end

However, I think this kind of change would be too drastic, and it has performance implications which make it undesirable in C++.

Array comprehensions

CoffeeScript’s for is a mechanism for array comprehensions rather than a simple loop:

foods = ['broccoli', 'spinach', 'chocolate']
eat(food) for food in foods when food != 'chocolate'

While this is nice, I don’t think this would add that much to the range-based for syntax and functional style iteration already available in C++.

No distinction between definition and assignment

CoffeeScript doesn’t make a distinction between variable definition and assignment, so that a = 10. It makes the syntax simpler, but it also makes shadowing impossible:

a = 10  # new variable
func = -> 
    a = 20  # assigns to the same a as above

This is a deliberate choice on the part of CoffeeScript’s creator. I think it’s dubious even in CoffeeScript, and would be worse in C++.

A longer example

Finally, here is a longer example of the new syntax and the normal C++ syntax side by side. This is based on some code I borrowed from the MongoDB project. In addition to using the new syntax on the left side, I made a few C++11/14 style changes.

/*    Copyright 2013 10gen Inc.
 *
 *    Licensed under the Apache License, Version 2.0 (the "License");
 *    you may not use this file except in compliance with the License.
 *    You may obtain a copy of the License at
 *
 *    http://www.apache.org/licenses/LICENSE-2.0
 *
 *    Unless required by applicable law or agreed to in writing, software
 *    distributed under the License is distributed on an "AS IS" BASIS,
 *    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 *    See the License for the specific language governing permissions and
 *    limitations under the License.
 */

#pragma once

#include <algorithm>
#include <cstdlib>

#include "mongo/base/status.h"
#include "mongo/logger/message_log_domain.h"

/*
 * Implementation of LogDomain<E>.  Include this in cpp files to instantiate new 
 * LogDomain types. See message_log_domain.h, e.g.
 */

namespace mongo 
    namespace logger 

        template <typename E>
        LogDomain<E>::LogDomain() :
            _minimumLoggedSeverity(LogSeverity::Log()), _abortOnFailure(false) \

        template <typename E>
        LogDomain<E>::~LogDomain() 
            clearAppenders()

        template <typename E>
        auto LogDomain<E>::append(const E& event) 
            for const auto& appender : _appenders
                if appender 
                    Status status = appender->append(event)
                    if !status.isOK()
                        if _abortOnFailure
                            ::abort()
                        return status

            return Status::OK()

        template <typename E>
        auto LogDomain<E>::attachAppender(
            typename LogDomain<E>::AppenderAutoPtr appender) 

            auto iter = std::find(_appenders.begin(), _appenders.end(), nullptr)

            if iter == _appenders.end()
                _appenders.push_back(appender.release())
                return AppenderHandle(_appenders.size() - 1)
            else 
                *iter = appender.release()
                return AppenderHandle(iter - _appenders.begin())

        template <typename E>
        auto LogDomain<E>::detachAppender(
            typename LogDomain<E>::AppenderHandle handle) 

            auto& appender = _appenders.at(handle._index)
            AppenderAutoPtr result(appender)
            appender = nullptr
            return result

        template <typename E>
        auto LogDomain<E>::clearAppenders() 
            for const auto& appender : _appenders
                delete appender
            _appenders.clear()

/*    Copyright 2013 10gen Inc.
 *
 *    Licensed under the Apache License, Version 2.0 (the "License");
 *    you may not use this file except in compliance with the License.
 *    You may obtain a copy of the License at
 *
 *    http://www.apache.org/licenses/LICENSE-2.0
 *
 *    Unless required by applicable law or agreed to in writing, software
 *    distributed under the License is distributed on an "AS IS" BASIS,
 *    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 *    See the License for the specific language governing permissions and
 *    limitations under the License.
 */

#pragma once

#include <algorithm>
#include <cstdlib>

#include "mongo/base/status.h"
#include "mongo/logger/message_log_domain.h"

/*
 * Implementation of LogDomain<E>.  Include this in cpp files to instantiate new 
 * LogDomain types. See message_log_domain.h, e.g.
 */

namespace mongo {
namespace logger {

    template <typename E>
        LogDomain<E>::LogDomain() 
        : _minimumLoggedSeverity(LogSeverity::Log()), _abortOnFailure(false) 
    {}

    template <typename E>
    LogDomain<E>::~LogDomain() {
        clearAppenders();
    }

    template <typename E>
    Status LogDomain<E>::append(const E& event) {
        for (typename AppenderVector::const_iterator iter = _appenders.begin();
             iter != _appenders.end(); ++iter) {

            if (*iter) {
                Status status = (*iter)->append(event);
                if (!status.isOK()) {
                    if (_abortOnFailure) {
                        ::abort();
                    }
                    return status;
                }
            }
        }
        return Status::OK();
    }

    template <typename E>
    typename LogDomain<E>::AppenderHandle LogDomain<E>::attachAppender(
            typename LogDomain<E>::AppenderAutoPtr appender) {

        typename AppenderVector::iterator iter = std::find(
                _appenders.begin(), _appenders.end(),
                static_cast<EventAppender*>(NULL));

        if (iter == _appenders.end()) {
            _appenders.push_back(appender.release());
            return AppenderHandle(_appenders.size() - 1);
        }
        else {
            *iter = appender.release();
            return AppenderHandle(iter - _appenders.begin());
        }
    }

    template <typename E>
    typename LogDomain<E>::AppenderAutoPtr LogDomain<E>::detachAppender(
            typename LogDomain<E>::AppenderHandle handle) {

        EventAppender*& appender = _appenders.at(handle._index);
        AppenderAutoPtr result(appender);
        appender = NULL;
        return result;
    }

    template <typename E>
    void LogDomain<E>::clearAppenders() {
        for(typename AppenderVector::const_iterator iter = _appenders.begin();
            iter != _appenders.end(); ++iter) {

            delete *iter;
        }

        _appenders.clear();
    }

}  // namespace logger
}  // namespace mongo

I think the code on the left is much easier to understand thanks to reduced clutter. It also means that bugs would be easier to spot, and it would be faster to scan through, e.g. when looking for a particular function.

Another thing to note is that the new syntax results in substantial savings in terms of line count. If I don’t include the large comment at the top, the normal C++ code is 25% longer than my syntax. That’s despite the fact that it uses Java-style formatting for curly braces. If opening curly braces were on their own lines, the difference would be even more significant.

I believe this vertical compression is valuable, because it can make a difference between seeing a whole function or only part of it, a whole algorithm or only a portion. Seeing the whole thing at once makes it easier to understand it and reason about it.

The end

Are there other problems with parsing this syntax which I haven’t thought of? This is C++, so I’m sure there are! Even without trying to make significant changes to the syntax, C++ parsing is a complicated affair. Plus of course, C++ was never designed with significant whitespace in mind.

My intent was to see if this kind of change would be at all plausible, and what it would make the code look like. It seems that it could work, but it would likely require constraints to be placed on some of the things which can be written in regular C++.

If you spotted a particular problem, feel free to point it out in the comments.

An overview of C++14 language features

Mon, 21 Apr 2014 00:00:00 +0000

In this post, I’m going to highlight some of the new language features in the draft of the C++14 standard. This is an excerpt from my book C++11 Rocks: VS2013 Edition. I looked at the level of C++14 support in different compilers in a previous post.

Return type deduction for functions

The compiler will be able to deduce the return type of functions:

auto square(int n) 
{
    return n * n;
}

To get the compiler to figure out the return type, you start the declaration with auto but don’t specify a trailing return type. This is basically extending the return type deduction VS2013 does for lambdas to regular functions.

Generic lambdas

When specifying lambda parameters, you’ll be able to use auto instead of a type:

auto lambda = [](auto a, auto b) { return a * b; };

In C++ pseudocode, this definition is equivalent to the following:

struct lambda1
{
    template<typename A, typename B>
    auto operator()(A a, B b) const -> decltype(a * b)
    {
        return a * b;
    }
};

auto lambda = lambda1();

So using auto for parameters effectively makes the function call operator templated. The types of the parameters will be determined using the rules for template argument deduction rather than the type inference that happens with regular auto variables.

Extended capturing in lambdas

Another change to lambdas involves capturing variables. In C++14, captured variables can have an initializing expression:

auto timer = [val = system_clock::now()] { return system_clock::now() - val; };
// ... do stuff ...
timer();   // returns time since timer creation

In this example, val is assigned the current time which is then returned by the lambda expression. val doesn’t need to be an existing variable, so this is in effect a mechanism for adding data members to the lambda. The types of these members are inferred by the compiler.

This allows capturing move-only variables which isn’t possible in C++11:

auto p = make_unique<int>(10);
auto lmb = [p = move(p)] { return *p; }

It is equivalent to capturing a variable via move, although what’s happening under the hood is a bit more tricky. In reality, the capture block declares a new data member in the lambda called p. This member is initialized with p from outside the lambda which is cast to an rvalue reference.

Revised restrictions on constexpr functions

The proposal lists the following things which are going to be allowed in constexpr functions:

declarations in constexpr functions with the exception of static, thread_local or uninitialized variables
if and switch statements
looping constructs, including range-based for
modification of objects whose lifetime began within the constant expression evaluation.

This should make constexpr functions a lot more versatile.

constexpr variable templates

In addition to type and function templates, C++14 will allow constexpr variables to be templated. Here is how it will work:

template<typename T>
constexpr T pi = T(3.1415926535897932385);

There is no new syntax, the already existing template syntax is simply applied to a variable here. This variable can then be used in generic functions:

template<typename T>
T area_of_circle_with_radius(T r) 
{
    return pi<T> * r * r;
}

The idea is that despite having a single initializing expression, it’s sometimes useful to vary the type of a variable used in a generic function.

More changes

There are more language changes on the way. They include: [list style=”arrow” color=”blue”]

Another alternative for type inference which will allow you to use decltype inference rules for auto variables.
Aggregate initialization will work for classes with in-class member initializers.
Built-in binary literals prefixed with 0b.
It’ll be possible to separate digits in a numeric literal with a single quote.
Another standard attribute called [[deprecated]] will be added with the purpose of marking deprecated parts of the code. [/list]

The standard is expected to be finalized some time this year. The good thing is that the work on adding new features into compilers is already well under way, and some of the features I described in this post can already be used.

C++11/14 compiler and library shootout

Tue, 04 Mar 2014 00:00:00 +0000

It’s been almost a year since my last comparison of C++11 support across different compilers, so I decided to take a break from working on my book about C++11/14 features in VS2013, and see how things have changed.

Once again, I’d like to see how different compilers stack up based on the documentation for the pre-release versions of these compilers. I’ve also included some of the current released versions for comparison.

Of course, now we have C++14 to think about in addition to C++11, so I’ve included C++14 in this comparison too.

The pre-release versions of the compilers are as follows: GCC 4.9, Clang 3.4 and Visual Studio Nov 2013 CTP.

First, let’s look at the C++11 language features. Clang 3.3 and above, and GCC 4.8 and later have complete support, so there was no point including them in the table.

C++11 language features support

Feature	VS Nov 2013 CTP	VS2013	Intel 14.0
auto	Yes	Yes	Yes
decltype	Yes	Yes	Yes
Lambda expressions	Yes	Yes	Yes
nullptr	Yes	Yes	Yes
static_assert	Yes	Yes	Yes
Range based for loop	Yes	Yes	Yes
Trailing return type in functions	Yes	Yes	Yes
extern templates	Yes	Yes	Yes
>> for nested templates	Yes	Yes	Yes
Local and unnamed types as template arguments	Yes	Yes	Yes
Variadic macros	Yes	Yes	Yes
Variadic templates	Yes	Yes	Yes
Default template arguments in function templates	Yes	Yes	Yes
final method keyword	Yes	Yes	Yes
override method keyword	Yes	Yes	Yes
Strongly typed enums	Yes	Yes	Yes
Forward declared enums	Yes	Yes	Yes
Explicit type conversion operators	Yes	Yes	Yes
Raw string literals	Yes	Yes	Yes
Delegating constructors	Yes	Yes	Yes
Template aliases	Yes	Yes	Yes
Non-static data member initializers	Yes	Yes	Yes
Deleted methods	Yes	Yes	Yes
Initializer lists	Yes	Partial	Yes
Rvalue references and move semantics	Yes	Partial	Yes
Defaulted methods	Yes	Partial	Yes
C99 compatibility	Partial	Partial	Yes
New built-in types	Partial	Partial	Partial
Member function ref qualifiers	Yes	No	Yes
noexcept	Partial	No	Yes
constexpr	Partial	No	Yes
Alignment support	Yes	Partial	No
Magic statics	Yes	No	Partial
Thread local storage	Partial	Partial	No
Generalized attributes	No	No	Yes
Inline namespaces	No	No	Yes
sizeof on non-static data members without an instance	Yes	No	No
Encoding support in literals	No	No	Yes
Arbitrary expressions in template deduction contexts	No	No	Yes
Inheriting constructors	Yes	No	No
Changed restrictions on union members	No	No	Partial
User defined literals	No	No	No

It looks like the Intel compiler is on par with the Visual Studio CTP. But Intel’s 14.0 compiler has been out for some time, while VS CTP is an alpha quality compiler, which means that Visual Studio trails behind everybody else, unfortunately.

How about C++14 support? The C++ standard is still in draft, but some compilers already have extensive support for C++14 language features:

C++14 language features support

Feature	Clang 3.4	GCC 4.9	VS Nov 2013 CTP	Intel 14.0
Return type deduction for regular functions	Yes	Yes	Yes	No
Binary literals	Yes	Yes	No	Yes
Generic lambdas	Yes	Yes	Partial	No
Tweaked wording for contextual conversions	Yes	Yes	No	No
Runtime sized arrays with automatic storage duration	Yes	Yes	No	No
Initialized lambda captures	Yes	Yes	No	No
[[deprecated]] attribute	Yes	Yes	No	No
Single quotation mark as digit separator	Yes	Yes	No	No
C++ sized deallocation	Yes	Yes	No	No
Variable templates	Yes	No	No	No
Relaxed requirements on constexpr functions	Yes	No	No	No
Member initializers and aggregates	Yes	No	No	No
Avoiding/fusing memory allocations	Yes	N/A	No	No

As far as libraries go, libstdc++, libc++ and Microsoft’s libraries all have at least partial support for all the features introduced in C++11. So instead of detailing those, I’ll focus on C++14 features. Once again, this is for the latest pre-release versions of the libraries available today:

C++14 library features support

Feature	libc++	libstdc++	VS Nov 2013 CTP
make_unique	Yes	Yes	Yes
Improved operator functors	Yes	Yes	Yes
Additional template aliases for transformation type traits	Yes	Yes	Yes
Fixing constexpr member functions without const	Yes	Yes	No
exchange() utility function	Yes	Yes	No
Retrieving tuple elements by type	Yes	Yes	No
std::result_of and SFINAE	Yes	Yes	No
Improvements to integral_constant	Yes	Yes	No
User-defined literals for standard library types	Yes	Yes	No
More robust non-modifying sequence operations	Yes	Yes	No
Quoted string I/O manipulator	Yes	Yes	No
constexpr library additions: chrono	Yes	Yes	No
constexpr library additions: containers	Yes	Yes	No
constexpr library additions: utilities	Yes	Yes	No
constexpr library additions: complex	Yes	No	No
constexpr library additions: functional	Yes	No	No
Compile-time integer sequences	Yes	Yes	No
Shared locking	Yes	Yes	No
Heterogeneous comparison lookup in associative containers	Yes	No	No
Null forward iterators	Yes	No	No
Sized deallocation	No	No	No
Consistent metafunction aliases	No	No	No
Discouraging rand() in C++14	No	No	No

Conclusion

Clang is obviously leading on the C++14 conformance front. There are also quite a few features implemented in GCC as well.

The interesting thing is that the process of building compilers to conform to the latest C++ standard has accelerated in recent years. With C++14, Clang has complete language support even before the standard has been finalized.

But it would be really great if Microsoft and Intel picked up their game, and brought their compilers’ conformance to the level of Clang and GCC.

44 C++11 bugs fixed in Visual Studio 2013

Mon, 24 Feb 2014 00:00:00 +0000

The following bugs which I described in the VS2012 edition of my book, C++11 Rocks, have been fixed in Visual Studio 2013, so you have more freedom to use C++11 features as they were intended to be used. If you used workarounds for these bugs, now you can remove them and clean up your code!

However, as I was researching VS2013, I was disappointed to learn that many bugs migrated from VS2012 unscathed, and new bugs have been introduced too. I’m working on describing these bugs in the VS2013 edition of C++11 Rocks.

Read on to find out which VS2012 bugs have been fixed!

No more type argument limits on variadic templates

This fixes a whole set of variadic templates in the standard library. As Visual Studio 2013 supports variadic templates, things like std::function or make_shared no longer have a limit on the number of template arguments they can take. There used to be a max of about 5 arguments by default in Visual Studio 2012.

Fixed type inference bugs

auto lost alignment specifiers

If you used auto to declare a variable of a type that’s qualified with __declspec(align(...)), the qualifier may not have been preserved in VS2012, which resulted in incorrect alignment and subsequent crashes.

decltype wasn’t always allowed in place of a type

Even though decltype is considered to be a type specifier, and the intention is for you to be able to use decltype(expr) in place of a type name anywhere, VS2012 didn’t allow code like this:

vector<int> a; 
decltype(a)::iterator iter = a.end(); // error in VS2012

declval caused compilation errors

Some correct code failed to compile in VS2012 because of declval internals (using add_rvalue_reference template).

Suppose you want to define an is_comparable<T> template:

template<typename, typename = true_type>
struct is_comparable : public false_type 
{};

template<typenameT>
struct is_comparable<T,
    typename is_convertible<decltype(declval<T>() > declval<T>()), 
        bool>::type> : public true_type 
{};

This didn’t compile because declval failed to handle T.

Fixed smart pointer bugs

Using a lambda as a custom deleter for unique_ptr breaks conversion to bool

If you used a lambda as a custom deleter in VS2012, and specified the type of the lambda as the deleter type (using decltype), you weren’t able to use the pointer in a boolean context:

auto stream_deleter = [](ofstream* os) { os->close(); };
unique_ptr<ofstream, decltype(stream_deleter)> p_log(&log_file, stream_deleter);

if (!p_log)     // compile error 
    cout << "Couldn't open file" << endl;

Calling unique_ptr::reset could cause a double delete

The order of operations in the reset method didn’t follow the order prescribed by the standard before VS2013. This could result in a double delete. The following (contrived) example shows how this happened:

class SelfReferential
{
    unique_ptr<SelfReferential>& _p_self;
public:
    SelfReferential(unique_ptr<SelfReferential>& p) : _p_self(p)
    {}
    ~SelfReferential() 
    {
        _p_self.reset();
    }
};

unique_ptr<SelfReferential> p;
p = unique_ptr<SelfReferential>(new SelfReferential(p));
p.reset();  // double delete via ~SelfReferential

The call to reset invokes SelfReferential’s destructor, which in turns calls reset again. The double delete happened because the reset method reset the pointer to the owned object after deleting it instead of before.

shared_ptr, protected destructor and nullptr

You could’t construct a shared_ptr of a class with a protected destructor with nullptr:

class Interface
{
public:
    virtual void do_stuff() = 0;

protected:
    ~Interface() {}
};

class Implementation : public Interface
{
public:
    void do_stuff() override
    {
        // ...
    }
};

shared_ptr<Interface> ptr1 = make_shared<Implementation>(); // OK
shared_ptr<Interface> ptr2 = nullptr;                       // error

In Visual Studio 2013, this code compiles as expected.

Fixed bugs in the type traits library

Wrong answers given for functions

is_function yielded the wrong result if given a function with too many arguments:

typedef void f(int, bool, int*, int[], int, int, int, int, int, int, int);
is_function<f>::value;     // false but should be true

It also incorrectly yielded false for functions with a non-default calling convention.

Similarly, is_member_function_pointer failed to detect member functions with an explicitly specified calling convention.

is_member_pointer, in contrast, failed to detect a __cdecl member:

typedef void (__cdecl A::*ccall_proc)(int, long, double);
is_member_pointer<ccall_proc>::value;   // false but should be true

is_object was defined in terms of is_function, so it produced an incorrect result (falsely detecting an object) if it was given a function with too many arguments (i.e. a function which also tripped up is_function as described above).

is_scalar refused to acknowledge nullptr_t

is_scalar<nullptr_t> incorrectly returned false in VS2012 – the standard requires nullptr_t to be considered a scalar type.

is_pod misidentified void

is_pod<void> incorrectly returned true in VS2012, even though void isn’t a POD type.

is_constructible gave wrong answers for reference types

is_constructible behaved incorrectly with reference types, returning false for things like this:

is_constructible<const string&, string>::value;
is_constructible<const string&, string&&>::value;

alignment_of in VS2012 generatee a spurious warning about inaccessible destructor if you used it on a type with a private destructor.

Additionally, the aligned_union template wasn’t well behaved in VS2012. It returned incorrect results in some cases:

typedef aligned_union<16, string>::type StorageType;
sizeof(string);       // produces 24
sizeof(StorageType);  // produces 16 but should be 24 or more

In addition to the member typedef type, aligned_union is also supposed to have a static member variable alignment_value containing the value of the strictest alignment of template arguments T1, …, Tn. However, it wasn’t present in the VS2012 implementation.

common_type incorrectly produced void

Instead of failing to compile as the definition of common_type implies in the standard, it could yield void in VS2012:

common_type<int, string>::type;     // void

common_type also yielded void incorrectly for user defined types where conversion is possible:

struct A {};

struct AWrapper {
    AWrapper() {}
    AWrapper(const A&) {}
};

common_type<A, AWrapper>::type;     // void

result_of failed to compile in some cases

If you attempt to use move-only argument types with this template in VS2012, you ran into trouble:

result_of<Copyable(MoveOnly&&)>::type;  // compile error

Fixed STL container and algorithm bugs

minmax_element algorithm didn’t work

There are two versions of this algorithm defined in the standard:

pair<Iter, Iter> minmax_element(Iter first, Iter last)
pair<Iter, Iter> minmax_element(Iter first, Iter last, Compare comp)

They should return the first iterator in [first, last) pointing to the smallest element, and the last iterator pointing to the largest element (in terms of comp if supplied), or make_pair(first, first) if the range is empty. However, in VS2012, it returned make_pair(min_element(first, last), max_element(first, last)) instead.

Containers incorrectly required element move constructors

All of the container move constructors incorrectly require element types to provide a move constructor:

struct A
{
    A() {}
private: 
    A(A&&);
    A(const A&);
};

deque<A> source;
deque<A> target(move(source));    // compile error

Additionally, they didn’t preserve the allocator during the move operation.

Similarly, map and unordered_map element access operators unnecessarily required the value type to be move constructible:

map<string, A> m;
A& elem = m["abc"];  // compile error

Fixed bugs in concurrency libraries

A bunch of bugs were fixed in the various parts of the concurrency libraries.

shared_future constructed from future

Another bug in VS2012 was in the implementation of the specializations of future and shared_future for reference types and void. This bug allowed code like this to compile (which is obviously wrong as future is a move-only type):

future<int&> f_ref; 
shared_future<int&> sf_ref(f_ref);    // compiles but shouldn't 

future<void> f_void;
shared_future<void> sf_void(f_void);  // compiles but shouldn't

Memory leak in the thread class

There is a bug which could lead to memory leaks being reported on program termination. This was due to the thread constructing and never destroying at_thread_exit_mutex, as well as some internal allocations in mutex and condition_variable which could be incorrectly reported as leaks.

Useless wait functions in a future provided by promise

There was a significant downside to using a future provided by a promise. Due to a bug in Visual Studio 2012, the wait_for and wait_until methods of such future objects returned future_status::deferred instead of future_status::timeout or future_status::ready, rendering these methods useless.

Incorrect messages in future_error exceptions

There was an off-by-one error between error codes and error messages returned via future_error, so you couldn’t rely on the message of future_error. For example, when you got a “broken promise” exception, the message would be “future already retrieved”. The error code was correct, however.

atomic template couldn’t be instantiated with a non-default-constructible type

You received an unwarranted compilation error if you tried to use a type without a default constructor with atomic.

atomics were slow

In VS2012, many atomic operations always enforced sequential consistency, which made them unnecessarily slow. While this didn’t violate the standard, it mostly defeated the purpose of having relaxed memory ordering - as it’s specifically meant to be used where high performance is required. VS2013 provides a different implementation of atomic operations which is much faster.

Fixed random number facility bugs

In debug mode, mersenne_twister_engine produced an incorrect assert if you tried to use zero as a seed.

The streaming operator for subtract_with_carry_engine contained an off-by-one error which triggered undefined behavior.

Both independent_bits_engine and shuffle_order_engine failed to initialize member variables in their move constructors, which sometimes resulted in infinite loops.

Fixed rational arithmetic library bugs

This library suffered from a remarkable number of defects.

Due to the lack of alias templates in VS2012, you couldn’t write

ratio_add<ratio<1, 2>, ratio<1, 3>>::num;
ratio_add<ratio<1, 2>, ratio<1, 3>>::den;

Instead, you had to refer to the numerator and denominator of the result via the type member:

ratio_add<ratio<1, 2>, ratio<1, 3>>::type::den;

Another issue was due to how comparison was implemented. It used ratio template arguments instead of using num and den static members as the standard requires. Because of this, if you used non-normalized numerator and denominator as ratio arguments, comparisons would provide an incorrect result:

cout << "2/60 < -1/3: " << ratio_less<r2_60, r1_3>::value << endl;  // false

cout << "2/60 < 1/-3: " << ratio_less<r2_60, ratio<1, -3>>::value 
    << endl;    // true but should also be false

So in VS2012, you had to make sure the denominator passed to ratio was always a positive number.

Another bug was that ratio_equal detected inequality but wasn’t very good at detecting equality:

ratio_equal<ratio<1, 4>, ratio<4, 16>>::value;   // false but should be true

Here is another bug. When you have a ratio<N, D>, if D is zero or either argument overflowed the boundaries of intmax_t, then your program is ill-formed. However, Visual Studio 2012 mostly failed to detect these issues:

typedef ratio<1, 0> r_error;
cout << r_error::den << endl;   // shouldn't compile but does

typedef ratio<INTMAX_MIN, 1> r_error2; 
cout << r_error2::num << endl;  // shouldn't compile but does

In the Visual Studio implementation, the static_assert statements which are supposed to trigger compilation errors in these situations reside in the ratio constructor. However, the compiler only triggers the static_assert’s in a constructor when the class is instantiated. You wouldn’t normally create instances when using ratio, so be aware that errors won’t be triggered at compile time.

Similarly, some of the operations compile incorrectly when they shouldn’t:

// shouldn't compile but does – with a warning about overflow
ratio_multiply<ratio<1, INTMAX_MAX>, ratio<1, 2>>::type;

Note that the statement ratio<1, 0> should actually compile whereas ratio<1, 0>::num shouldn’t. This is because errors are only detected when one of the members is evaluated.

Other bugs fixed in Visual Studio 2013

tuple_element bounds checking wasn’t done

tuple_element<I, array<T, N>> is supposed to check that I < N and fail to compile if it isn’t. This wasn’t done until VS2013.

Wrong conversion to bool for std::function

In some cases, the conversion could produce an incorrect result in VS2012 due to the function object not being empty when it should be. For example:

// JetPlane derives from Plane
function<bool(JetPlane*)> plane_ready_func = function<bool(Plane*)>();
if (plane_ready_func)   // should yield false but doesn't
{
    plane_ready_func(nullptr);   // gets called and throws bad_function_call
}

Assignment to rvalues

Visual Studio 2012 didn’t forbid assignment to rvalues as required by the standard:

struct Dummy 
{ 
    int _x; 
};
Dummy get_dummy() 
{ 
    Dummy d = { 10 }; 
    return d; 
}
get_dummy()._x = 20;     // compiles even though it shouldn't

align() updated out parameters incorrectly

The function correctly calculated the address it returns, but updated the last two parameters incorrectly:

void* p = (void*)0x1;

// try to align 200 bytes to the 32 byte boundary 
// with 230 bytes of storage space available
size_t space = 230;
void* res = align(32, 200, (void*&)p, space);  
// res is null as 31 bytes are needed for alignment
// but at most 30 are available

space = 256;  // increase available space to 256 bytes
res = align(32, 200, (void*&)p, space);
// res is now 0x20 (aligned to 32 byte boundary)
// p is 0xE8 (200 + 32) but should be 0x20
// space is 25 but should be 225

time_put didn’t work with wchar_t

time_put didn’t produce output when instantiated with wchar_t.

Conclusion

For a full list of library changes in VS2013 (not just those related to C++11), you can check out this post by Stephan Lavavej.

In addition to adding new C++11 features, Visual Studio 2013 fixes a significant number of bugs in the existing C++11 functionality in the compiler and libraries, from incorrect compiler errors to memory leaks to poor performance. This is definitely a good thing.

Unfortunately, VS2013 still contains a large number of bugs carried over from VS2012. It also introduces new bugs related to C++11 features. If you don’t want to get stung by these bugs, check out the VS2013 edition of my C++11 Rocks book. Even though it’s currently in beta, it already describes a significant number of Visual Studio bugs.

10 new C++11 features in Visual Studio 2013

Mon, 03 Feb 2014 00:00:00 +0000

The Visual Studio 2013 C++ compiler has a number of new C++11 features. I’d like to give you a quick overview of these features using examples from the upcoming VS2013 edition of my book, C++11 Rocks.

1. Variadic templates

Before C++11, if you wanted a template which could work with a variable number of type (or non-type) parameters, you had no choice but to limit such a template to a fixed maximum number of parameters, and the implementation usually involved fairly nasty preprocessor use. To solve this problem, C++11 introduces variadic templates - that is, templates which can have an arbitrary number of type parameters:

template<typename Stream, typename... Columns>
class CSVPrinter
{
public:
    void output_line(const Columns&... columns);

    // other methods, constructors etc. not shown
};

The template can be instantiated with int, double and string, for example:

CSVPrinter<decltype(stream),
     int, double, string> printer;

The output_line method of this instantiation is equivalent to this:

void output_line(const int& col1,
     const double& col2,
     const string& col3);

2. Alias templates

Template aliases allow you to create an alias for a template, but unlike a typedef, you only have to provide some of the template arguments:

template<typename T>
using StrKeyMap = map<string, T>;

StrKeyMap<int> counters;

StrKeyMap is an alias for the map template with the key type set to string, and is itself a template. Aliases allow you to simplify your code.

3. In-class initializers for non-static data members

C++11 gives you a new option for initializing non-static data members:

class JetPlane
{
public:
    string _model = "Unknown";
};

Instead of initializing members in constructors, you can add an in-class initializer to the member declaration. This allows you to avoid duplication when you have multiple constructors.

4. Defaulted functions

The compiler can generate a default constructor, destructor, copy constructor and copy assignment operator.

However, if you declare your own constructor, it prevents the generation of the default version. If you declare your own copy operations, then the compiler won’t generate the move operations, and so on.

But sometimes, it’s convenient to preserve some of these default operations, so C++11 provides a way to explicitly request default implementations from the compiler:

class JetPlane
{
public:
    JetPlane() = default;
    JetPlane(const JetPlane& other); 
};

5. Deleted functions

You can also apply the delete keyword to methods, which is sort of the opposite to default. delete means that the function doesn’t have an implementation, it’s uncallable and can’t be used in any way. One use for it is to disable compiler-generated methods:

class JetPlane
{
public:
    JetPlane() = default;
    JetPlane(const JetPlane&) = delete;
    JetPlane& operator=(const JetPlane&) = delete;
};

This example disables copying of JetPlane class instances.

6. Delegating constructors

C++11 allows a constructor to call another constructor (i.e. delegate to it):

class JetPlane
{
public:
    JetPlane() : JetPlane(2, "Unknown", "Unknown")
    {}
};

This can be a good way to reduce duplication in initialization code.

7. Raw string literals

Raw literals can’t contain any special characters, allowing you to have things like backslashes, quotes or what would normally be escape sequences like \n in your string literals:

cout << R”(use “\n” to represent newline)” << endl;

This is going to output the string literal verbatim, without any translation, so you’ll see the quotes and \n in the output.

This is a convenient way to write regular expressions. Instead of

"\”\\w+\\\\\\w+\”"

you can simply write

R"(”\w+\\\w+”)".

8. Explicit conversion operators

In addition to explicit constructors, you can now declare conversion operators explicit too. It allows you to prevent unwanted implicit conversion. For example, the standard template std::function has an explicit operator bool:

explicit operator bool() const noexcept;

9. Default values for function template parameters

Before C++11, you could provide default values for class template parameters, but not for function templates. This has been rectified, so you can create templates like this one:

template<typename T, typename Cont = vector<T>> Cont get_batch(T seed);

The second template parameter provides a default value for the return type.

10. Uniform initialization & initializer_list

C++11 makes an attempt to make initialization more uniform by introducing . All of the examples I’ve shown you, both working and not working, can now be written using brace initialization:

int x {5};
int* p_values = new int[3] {1, 2, 3};

Unfortunately, this mechanism has plenty of caveats of its own, so I can’t recommend it as a replacement for the traditional initialization syntax.

Other changes

In addition, the STL implementation has been updated to use these features where necessary. Previously it was using various workaround to simulate the behavior required by the C++11 standard. Numerous changes have been made to fix bugs in the standard library, including an overhaul of <type_traits> and <ratio> libraries. <atomic> had a rewrite in order to improve its performance.

VS2013 bugs & C++11 Rocks VS2013 edition

I’m getting ready to release the beta version of C++11 Rocks VS2013 edition which will provide detailed information about all of these changes.

My preliminary testing indicates that many of the new language features come with their share of bugs in the Visual Studio implementation, and the final version of the book will explain what they are, and how to work around them if possible.

The book will be available as a PDF, and in EPUB and Mobi formats. The beta version will contain all the chapters, but it won’t have information on the compiler/library bugs. It will also require some editing and proofreading.

However, while the book is in beta you’ll be able to get it at a discounted price. And once it’s finished, you’ll get the final release at no extra charge!

C++11 concurrency cheatsheet

Tue, 06 Aug 2013 00:00:00 +0000

Parallel execution. It’s where programming is shifting - slowly but inexorably - and, of course, C++11 is on the concurrency bandwagon. Futures/promises, threads, condition variables and so on - it’s all part of the standard library.

I thought it would be handy to have a summary of the concurrency classes and their methods on a single page for quick reference. So I made a cheatsheet:

Download C++ concurrency cheatsheet

I hope you’ll find it useful. Note that it isn’t exhaustive - e.g. I had to omit atomics because of space constraints. The majority of concurrency features are supported across Visual Studio 2012, GCC 4.8 and Clang 3.3 (see this post for more details). This means that it’s possible to write cross-platform code that runs on multiple cores without relying on third-party libraries. I think that’s pretty cool!

Are there other parts of C++ you would like to see summarized, documented or explained? Leave a comment below, I’m always looking for ideas.

C++11 compiler support shootout: Visual Studio, GCC, Clang, Intel

Thu, 14 Mar 2013 00:00:00 +0000

It’s been more than half a year since my last comparison of the C++11 support across different compilers. This time I’d like to see how different compilers stack up based on the documentation for the pre-release versions of these compilers.

The next release of GCC is 4.8 and the upcoming version of Clang is 3.3. If you use Visual Studio 2012, you can install an experimental CTP update released in November 2012 to get additional C++11 features.

I’ve also thrown in v.13.0 of Intel’s C++ compiler out of curiosity, although it isn’t pre-release and there were a few features I couldn’t find information about. I didn’t find any information about the upcoming version of this compiler.

Feature	VS2012 Nov CTP	g++ 4.8	Clang 3.3	Intel 13.0
auto	Yes	Yes	Yes	Yes
decltype	Yes	Yes	Yes	Yes
Rvalue references and move semantics	Yes	Yes	Yes	Yes
Lambda expressions	Yes	Yes	Yes	Yes
nullptr	Yes	Yes	Yes	Yes
static_assert	Yes	Yes	Yes	Yes
Range based for loop	Yes	Yes	Yes	Yes
Trailing return type in functions	Yes	Yes	Yes	Yes
extern templates	Yes	Yes	Yes	Yes
>> for nested templates	Yes	Yes	Yes	Yes
Local and unnamed types as template arguments	Yes	Yes	Yes	Yes
Variadic macros	Yes	Yes	Yes	Yes
Variadic templates	Yes	Yes	Yes	Yes
Default template arguments in function templates	Yes	Yes	Yes	Yes
final method keyword	Yes	Yes	Yes	No
override method keyword	Yes	Yes	Yes	No
Strongly typed enums	Yes	Yes	Yes	Partial
Forward declared enums	Yes	Yes	Yes	Partial
Initializer lists	Yes	Yes	Yes	Partial
explicit type conversion operators	Yes	Yes	Yes	No
Raw string literals	Yes	Yes	Yes	No
Forwarding constructors	Yes	Yes	Yes	No
Template aliases	No	Yes	Yes	Yes
Defaulted methods	No	Yes	Yes	Yes
Deleted methods	No	Yes	Yes	Yes
Generalized attributes	No	Yes	Yes	Yes
New built-in types	Partial	Yes	Yes	Partial
Alignment support	Partial	Yes	Yes	No
Inline namespaces	No	Yes	Yes	No
sizeof on non-static data members without an instance	No	Yes	Yes	No
Changed restrictions on union members	No	Yes	Yes	No
User defined literals	No	Yes	Yes	No
Encoding support in literals	No	Yes	Yes	No
Arbitrary expressions in template deduction contexts	No	Yes	Yes	Don't know
Non-static data member initializers	No	Yes	Yes	Don't know
noexcept	No	Yes	Yes	Partial
constexpr	No	Yes	Yes	Partial
C99 compatibility	Partial	Partial	Partial	Yes
Thread local storage	Partial	Yes	No	Partial
Inheriting constructors	No	Yes	No	No
Rvalue references for *this	No	No	Yes	No

It looks like GCC is overtaking Clang as the compiler with the best C++11 support. Visual Studio has added several significant C++11 features such as variadic templates, initializer lists and raw literals.

I can’t really comment on how complete and bug-free these implementations are at a more fine grained level (other than VS2012 - I detail a lot of the bugs in the initial VS2012 release in my book, C++11 Rocks).

It’s also useful to look at the state of library support. I’m not going to get very specific as there are lots of small changes across the standard library. I’m also going to omit Intel’s library from this comparison.

I can say that the major additions to the library are mostly provided by all three implementations (as shown in the table below), although with various caveats.

Microsoft’s library implementation lacks anything that requires unimplemented language features such as constexpr (as of the initial release of VS2012). The library hasn’t been updated to use the features in the November 2012 CTP of the compiler such as initializer lists or variadic templates.

GCC’s libstdc++ lags somewhat as it doesn’t support regular expressions and low-level concurrency features. It also doesn’t implement constexpr methods in a lot of cases. std::function doesn’t have support for custom allocators, as Gilad noted in the comments below.

Clang’s libc++ is 100% complete on Mac OS, however various parts of it don’t yet work on Windows and Linux.

Feature	MSVC	libstdc++	libc++
Concurrency: async/future/promise/packaged_task	Yes	Yes	Yes
Concurrency: thread and related	Yes	Yes	Yes
Concurrency: condition variables	Yes	Yes	Yes
Concurrency: mutexes	Yes	Yes	Yes
Concurrency: atomic types and operations	Yes	Yes	Yes
Concurrency: relaxed memory ordering and fences	Yes	No	Yes
Smart pointers	Yes	Yes	Yes
Tuples	Yes	Yes	Yes
std::bind	Yes	Yes	Yes
std::function	Yes	Yes	Yes
Regular expressions	Yes	No	Yes
Type traits	Yes	Partial	Yes
std::forward_list	Yes	Yes	Yes
std::array	Yes	Yes	Yes
Hash tables	Yes	Yes	Yes
Random number generation	Yes	Yes	Yes
Compile time rational numbers (ratio)	Yes	Yes	Yes
Time utilities (chrono)	Yes	Yes	Yes
Initializer lists	Yes	Yes	Yes
Diagnostics (system_error)	Yes	Yes	Yes
STL refinements and new algorithms	Yes	Yes	Yes
General purpose (move, forward, declval etc.)	Yes	Yes	Yes
Minimal support for garbage collection	Yes	No	No

It’s good to see that the language and library support is steadily improving. Clang and GCC are getting close to having full C++11 support. Visual Studio is also improving C++11 support, and I’m pleased that C++ compiler updates are happening between major releases. The list of supported features in Intel’s compilers is growing longer as well.

Who knows, by next year all four compilers might support all the C++11 features!

C++ Rocks!

JetBrains CLion C++ IDE First Impressions

What do I want from an IDE?

Getting Started with CLion

The Editor

Code Completion and Interactive Feedback

Project navigation

Builds

Debugging

Refactoring and Code Fixes

Extras

Conclusion

Clang edition of the C++11/14 Rocks book

Spotlight on libraries relying on C++14

What if C++ looked more like Python or CoffeeScript?

Newline and semicolon as statement separators

Multiline statements

Optional parentheses in control structures

Declarations vs definitions

Method access specifiers

Lambdas

Standalone code blocks

Things I don’t know how to handle

Syntactic constructs that wouldn’t work in C++

Treating everything as an expression and optional returns

Array comprehensions

No distinction between definition and assignment

A longer example

The end

An overview of C++14 language features

Return type deduction for functions

Generic lambdas

Extended capturing in lambdas

Revised restrictions on constexpr functions

constexpr variable templates

More changes

C++11/14 compiler and library shootout

C++11 language features support

C++14 language features support

C++14 library features support

Conclusion

44 C++11 bugs fixed in Visual Studio 2013

No more type argument limits on variadic templates

Fixed type inference bugs

auto lost alignment specifiers

decltype wasn’t always allowed in place of a type

declval caused compilation errors

Fixed smart pointer bugs

Using a lambda as a custom deleter for unique_ptr breaks conversion to bool

Calling unique_ptr::reset could cause a double delete

shared_ptr, protected destructor and nullptr

Fixed bugs in the type traits library

Wrong answers given for functions

is_scalar refused to acknowledge nullptr_t

is_pod misidentified void

is_constructible gave wrong answers for reference types

Bugs in alignment related type traits

common_type incorrectly produced void

result_of failed to compile in some cases

Fixed STL container and algorithm bugs

minmax_element algorithm didn’t work

Containers incorrectly required element move constructors

Fixed bugs in concurrency libraries

shared_future constructed from future

Memory leak in the thread class

Useless wait functions in a future provided by promise

Incorrect messages in future_error exceptions

atomic template couldn’t be instantiated with a non-default-constructible type

atomics were slow

Fixed random number facility bugs

Fixed rational arithmetic library bugs

Other bugs fixed in Visual Studio 2013

tuple_element bounds checking wasn’t done

Wrong conversion to bool for std::function

Assignment to rvalues

align() updated out parameters incorrectly

time_put didn’t work with wchar_t

Conclusion

10 new C++11 features in Visual Studio 2013

1. Variadic templates