Dec 10-12, free online: CodeRage 7 C++ conference, with special guest Bjarne Stroustrup

By Blog Staff | Nov 23, 2012 10:46 AM | Tags: None

CodeRage 7 is a free C++-themed online developer conference by Embarcadero, running from December 10-12 (Mon-Wed). Many of the sessions are vendor-specific, focusing notably on C++Builder, but there are two notable sessions likely of interest to C++ developers on all platforms.

SPECIAL SESSION: A C++ Conversation with Bjarne Stroustrup

Bjarne Stroustrup and David Intersimone

Monday, December 10th - 8:00am - 8:45am PST (find your local time)

Bjarne Stroustrup will discuss the ISO C++11 standard, new language features, how C++11 builds on C++’s strengths, application portability, and C++’s ubiquitous presence in the markets.

 

The Resurgence of C++ for Application Development

John Thomas - Embarcadero

Tuesday, December 11th - 9:00am - 9:45am PST (find your local time)

Why C++ is back and coming on strong, and not just for "infrastructure." Believe it.

More information...

On vector<bool> -- Howard Hinnant

By Howard Hinnant | Nov 22, 2012 12:20 PM | Tags: advanced

On vector<bool>

by Howard Hinnant

vector<bool> has taken a lot of heat over the past decade, and not without reason. However I believe it is way past time to draw back some of the criticism and explore this area with a dispassionate scrutiny of detail.

There are really two issues here:

1. Is the data structure of an array of bits a good data structure?
2. Should the aforementioned data structure be named vector<bool>?

I have strong opinions on both of these questions. And to get this out of the way up front:

1. Yes.
2. No.

The array of bits data structure is a wonderful data structure. It is often both a space and speed optimization over the array of bools data structure if properly implemented. However it does not behave exactly as an array of bools, and so should not pretend to be one.

First, what's wrong with vector<bool>?

Because vector<bool> holds bits instead of bools, it can't return a bool& from its indexing operator or iterator dereference. This can play havoc on quite innocent looking generic code. For example:

template <class T>
void
process(T& t)
{
    // do something with t
}

template <class T, class A>
void
test(std::vector<T, A>& v)
{
    for (auto& t : v)
        process(t);
}

The above code works for all T except bool. When instantiated with bool, you will receive a compile time error along the lines of:

error: non-const lvalue reference to type 'std::__bit_reference<std::vector<bool, std::allocator<bool>>, true>' cannot bind to
      a temporary of type 'reference' (aka 'std::__bit_reference<std::vector<bool, std::allocator<bool>>, true>')
    for (auto& t : v)
               ^ ~
note: in instantiation of function template specialization 'test<bool, std::allocator<bool>>' requested here
    test(v);
    ^
vector:2124:14: note: selected 'begin' function
      with iterator type 'iterator' (aka '__bit_iterator<std::vector<bool, std::allocator<bool>>, false>')
    iterator begin()
             ^
1 error generated.

This is not a great error message. But it is about the best the compiler can do. The user is confronted with implementation details of vector and in a nutshell says that the vector is not working with a perfectly valid ranged-based for statement. The conclusion the client comes to here is that the implementation of vector is broken. And he would be at least partially correct.

But consider if instead of vector<bool> being a specialization instead there existed a separate class template std::bit_vector<A = std::allocator<bool>> and the coder had written:

template <class A>
void
test(bit_vector<A>& v)
{
    for (auto& t : v)
        process(t);
}

Now one gets a similar error message:

error: non-const lvalue reference to type 'std::__bit_reference<std::bit_vector<std::allocator<bool>>, true>' cannot bind to
      a temporary of type 'reference' (aka 'std::__bit_reference<std::bit_vector<std::allocator<bool>>, true>')
    for (auto& t : v)
               ^ ~
note: in instantiation of function template specialization 'test<std::allocator<bool>>' requested here
    test(v);
    ^
bit_vector:2124:14: note: selected 'begin' function
      with iterator type 'iterator' (aka '__bit_iterator<std::bit_vector<std::allocator<bool>>, false>')
    iterator begin()
             ^
1 error generated.

And although the error message is similar, the coder is far more likely to see that he is using a dynamic array of bits data structure and it is understandable that you can't form a reference to a bit.

I.e. names are important. And creating a specialization that has different behavior than the primary, when the primary template would have worked, is poor practice.

But what's right with vector<bool>?

For the rest of this article assume that we did indeed have a std::bit_vector<A = std::allocator<bool>> and that vector was not specialized on bool. bit_vector<> can be much more than simply a space optimization over vector<bool>, it can also be a very significant performance optimization. But to achieve this higher performance, your vendor has to adapt many of the std::algorithms to have specialized code (optimizations) when processing sequences defined by bit_vector<>::iterators.

find

For example consider this code:

template <class C>
typename C::iterator
test()
{
    C c(100000);
    c[95000] = true;
    return std::find(c.begin(), c.end(), true);
}

How long does std::find take in the above example for:

1. A hypothetical non-specialized vector<bool>?
2. A hypothetical bit_vector<> using an optimized find?
3. A hypothetical bit_vector<> using the unoptimized generic find?

I'm testing on an Intel Core i5 in 64 bit mode. I am normalizing all answers such that the speed of A is 1 (smaller is faster):

1. 1.0
2. 0.013
3. 1.6

An array of bits can be a very fast data structure for a sequential search! The optimized find is inspecting 64 bits at a time. And due to the space optimization, it is much less likely to cause a cache miss. However if the implementation fails to do this, and naively checks one bit at a time, then this giant 75X optimization turns into a significant pessimization.

count

std::count can be optimized much like std::find to process a word of bits at a time:

template <class C>
typename C::difference_type
test()
{
    C c(100000);
    c[95000] = true;
    return std::count(c.begin(), c.end(), true);
}

My results are:

1. 1.0
2. 0.044
3. 1.02

Here the results are not quite as dramatic as for the std::find case. However any time you can speed up your code by a factor of 20, one should do so!

fill

std::fill is yet another example:

template <class C>
void
test()
{
    C c(100000);
    std::fill(c.begin(), c.end(), true);
}

My results are:

1. 1.0
2. 0.40
3. 38.

The optimized fill is over twice as fast as the non-specialized vector<bool>. But if the vendor neglects to specialize fill for bit-iterators the results are disastrous! Naturally the results are identical for the closely related fill_n.

copy

std::copy is yet another example:

template <class C>
void
test()
{
    C c1(100000);
    C c2(100000);
    std::copy(c1.begin(), c1.end(), c2.begin());
}

My results are:

1. 1.0
2. 0.36
3. 34.

The optimized copy is approaches three times as fast as the non-specialized vector<bool>. But if the vendor neglects to specialize fill for bit-iterators the results are not good. If the copy is not aligned on word boundaries (as in the above example), then the optimized copy slows down to the same speed as the copy for A. Results for copy_backward, move and move_backward are similar.

swap_ranges

std::swap_ranges is yet another example:

template <class C>
void
test()
{
    C c1(100000);
    C c2(100000);
    std::swap_ranges(c1.begin(), c1.end(), c2.begin());
}

My results are:

1. 1.0
2. 0.065
3. 4.0

Here bit_vector<> is 15 times faster than an array of bools, and over 60 times as fast as working a bit at a time.

rotate

std::rotate is yet another example:

template <class C>
void
test()
{
    C c(100000);
    std::rotate(c.begin(), c.begin()+c.size()/4, c.end());
}

My results are:

1. 1.0
2. 0.59
3. 17.9

Yet another example of good results with an optimized algorithm and very poor results without this extra attention.

equal

std::equal is yet another example:

template <class C>
bool
test()
{
    C c1(100000);
    C c2(100000);
    return std::equal(c1.begin(), c1.end(), c2.begin());
}

My results are:

1. 1.0
2. 0.016
3. 3.33

If you're going to compare a bunch of bools, it is much, much faster to pack them into bits and compare a word of bits at a time, rather than compare individual bools, or individual bits!

Summary

The dynamic array of bits is a very good data structure if attention is paid to optimizing algorithms that can process up to a word of bits at a time. In this case it becomes not only a space optimization but a very significant speed optimization. If such attention to detail is not given, then the space optimization leads to a very significant speed pessimization.

But it is a shame that the C++ committee gave this excellent data structure the name vector<bool> and that it gives no guidance nor encouragement on the critical generic algorithms that need to be optimized for this data structure. Consequently, few std::lib implementations go to this trouble.

Rule of Zero -- R. Martinho Fernandes

By R. Martinho Fernandes | Nov 22, 2012 11:42 AM | Tags: intermediate

Long-time C++98 developers know about the Rule of Three. But with C++11's addition of move semantics, we need to be talking instead about the Rule of Five.

This article argues for limiting the use of the Rule of Five, and instead mostly aiming for a "Rule of Zero" -- why you don't have and don't want to write logic for copying, for moving, and for destruction all the time in C++, and why you should encapsulate that logic as much as possible in the remaining situations when you actually need to write it. (And, in passing, he shows once again why C++11 developers seem to be drawn to reusing unique_ptrs with custom deleters like moths to flames bees to flowers. See also recent examples like this one on std-proposals.)

Rule of Zero

In C++ the destructors of objects with automatic storage duration are invoked whenever their scope ends. This property is often used to handle cleanup of resources automatically in a pattern known by the meaningless name RAII.

An essential part of RAII is the concept of resource ownership: the object responsible for cleaning up a resource in its destructor owns that resource. Proper ownership policies are the secret to avoid resource leaks...

Continue reading...

New site feature: Suggest an article

By Blog Staff | Nov 21, 2012 04:26 PM | Tags: None

This site hosts a curated blog that provides pointers to the best and latest content in the world on modern Standard C++. From links to fresh new articles and books, to product news, to useful videos and events, to (of course) news about the standardarization process itself, we want you to be able to find out about it from here.

We want to link to all high-quality C++ content. But how can we make sure we don't miss something good? The blog editors know about a lot of the latest news and content, but no one person or small group can catalog it all, and we don't want to miss anything that C++ developers might find good and useful.

You can help. It's easy, and here's how.

Have you recently come across a high-quality article? a useful video? an upcoming event? cool product news? or something else likely of interest to a large subset of C++ developers? Then let us know using a cool new feature of the site: The "Suggest an Article" link available at the top right of the screen whenever you're logged into the site. (If you don't have a login, it's easy to get one: Registration is free.)

When you click on the Suggest link, you'll be taken to a screen that looks something like this. Here, you can write a draft blog post for the Blog Editors' consideration:

• Enter a title, and the URL people should be taken to.
• Pick an appropriate category.
• Write a body that lets people know what it's about and why they should read/watch/follow the link.

As a guide, follow the style of existing blog posts already on this site. If you're curious, you can also check out the isocpp.org style guide used by our own editors; a subset of those features are available to you when writing blog suggestions.

You can make multiple suggestions and track their status via the Your Suggestions box on the right side of the suggestion page.

We can't accept all suggestions; some will be duplicates, others may not be deemed to be of wide enough interest to C++ developers. But many suggestions will be accepted -- if your post is accepted, the editors will edit it to tighten it up and conform to our style guide, and post it live for the world to see and appreciate with your name in the byline as the author of the blog post. If that happens to your suggestion, congratulations -- that's your name up there in bright lights on the home page of isocpp.org!

A few of you already found the Suggest link, and so we're happy to report that the very first user blog post suggestion by Blair Davidson went live today. Thanks, Blair, and thanks in advance to all who will help us find and link to the best high-quality C++ content in the world.

C++ Questions and Answers -- Herb Sutter

By Blair Davidson | Nov 21, 2012 03:23 PM | Tags: None

This blog post was suggested by Blair Davidson. The video is from summer 2011, shortly before the C++11 standard was ratified:

Herb Sutter: C++ Questions and Answers

Jun 07, 2011

Herb's [previous] appearance on C9 was a relatively short chat with me about C++0x. You wanted more questions asked and some of you thought I was just too soft on Herb. Well, Herb decided that the best way to get the questions you want asked is, well, to have you ask them. Most of the highest user-rated questions were asked and Herb answers with his usual precision. So, without further ado, it's C++ question and answer time with Herb Sutter, powered by you.

Continue reading...

scope(exit) in C++11

By Blog Staff | Nov 20, 2012 11:43 AM | Tags: intermediate

A C++ note in passing from an indie game developer. He notes that Boost has a similar feature already (see the BOOST_SCOPE_EXIT macros and discussion of alternatives) but likes that you can write the basic feature yourself in under 10 lines, have it work like a statement instead of a BEGIN/END macro pair, and use it with other C++11 features like lambdas.

scope(exit) in C++11

I really like the scope(exit) statements in D. They allow you to keep the cleanup code next to the initialization code making it much easier to maintain and understand. I wish we had them in C++.

Turns out this can be implemented easily using some of the new C++ features...

Continue reading...

Storage Layout of Polymorphic Objects -- Dan Saks

By Blog Staff | Nov 15, 2012 06:30 PM | Tags: advanced

It's great to see Dan writing about C++ again. Here's his latest today, in Dr. Dobb's:

Storage Layout of Polymorphic Objects

By Dan Saks

Adding at least one virtual function to a class alters the storage layout for all objects of that class type.

Adding at least one virtual function to a class alters the storage layout for all objects of that class type. In this article, I begin to explain how C++ compilers typically implement virtual functions by explaining how the use of virtual functions affects the storage layout for objects.

Continue reading...

(Not) Using std::thread -- Andrzej Krzemieński

By Blog Staff | Nov 15, 2012 05:54 PM | Tags: intermediate

Andrzej Krzemieński writes:

(Not) using std::thread

This post is about std::thread but not about threads or multi-threading. This is not an introduction to C++ threads. I assume that you are already familiar with Standard Library components thread and async.

I encountered a couple of introductions to C++ threads that gave a code example similar to the one below:

void run_in_parallel(function<void()> f1, function<void()> f2)

{

    thread thr{f1}; // run f1 in a new thread

    f2();           // run f2 in this thread

    thr.join();     // wait until f1 is done

}

While it does give you a feel of what thread’s constructor does and how forking and joining works, I feel it does not stress enough how exception-unsafe this code is, and how unsafe using naked threads in general is. In this post I try to analyze this “safety” issues...

Continue reading...

SG4 (Networking) wiki online

By Blog Staff | Nov 15, 2012 05:07 PM | Tags: None

Study Group 4 (SG4), which focuses on Networking topics, now has a wiki on GitHub for those who want to follow its work and near-term deliverables.

The link is also available via SG4's entry in the SG list on The Committee page.

Please contact the SG4 chair, Kyle Kloepper, for further information.

Reactive Extensions (Rx) now supports LINQ in C++, goes open source

By Blog Staff | Nov 15, 2012 04:40 PM | Tags: None

Reactive Extensions (Rx) is now open source and supports LINQ styles in C++.

From the announcement, Rx is already being used for a number of highly responsive applications including GitHub for Windows:

According to Paul Betts at GitHub, "GitHub for Windows uses the Reactive Extensions for almost everything it does, including network requests, UI events, managing child processes (git.exe). Using Rx and ReactiveUI, we've written a fast, nearly 100% asynchronous, responsive application, while still having 100% deterministic, reliable unit tests. The desktop developers at GitHub loved Rx so much, that the Mac team created their own version of Rx and ReactiveUI, called ReactiveCocoa, and are now using it on the Mac to obtain similar benefits."

In addition to Rx's original support for .NET and new support for Javascript, Rx has also added support for C++:

Rx++: The Reactive Extensions for Native (RxC) is a library for composing asynchronous and event-based programs using observable sequences and LINQ-style query operators in both C and C++.

Ix++: An implementation of LINQ for Native Developers in C++.

Where to download or find out more: https://rx.codeplex.com/