New Book “C++ Standard Library Quick Reference” Now Available

By Marc Gregoire | Jul 2, 2016 07:10 AM | Tags: None

Marc Gregoire’s and Peter Van Weert’s brand new book “C++ Standard Library Quick Reference”, published by Apress is now available:

C++ Standard Library Quick Reference (Apress) 
C++ Standard Library Quick Reference (Amazon)

By Marc Gregoire and Peter Can Weert

From the abstract:

This quick reference is a condensed reference guide to the essential data structures, algorithms, and functions provided by the C++ Standard Library. Used by millions of C++ programmers on a daily basis, the C++ Standard Library features core classes for strings, I/O streams, and various generic containers, as well as a comprehensive set of algorithms to manipulate them. In recent years, the C++11 and C++14 standards have added even more efficient container classes, a new powerful regular expression library, and a portable multithreading library featuring threads, mutexes, condition variables, and atomic variables.

Needless to say, it is hard to know and remember all the possibilities, details, and intricacies of this vast and growing library. This handy reference guide is therefore indispensable to any C++ programmer. It offers a condensed, well-structured summary of all essential aspects of the C++ Standard Library. No page-long, repetitive examples or obscure, rarely used features. Instead, everything you need to know and watch out for in practice is outlined in a compact, to-the-point style, interspersed with practical tips and well-chosen, clarifying examples. The book does not explain the C++ language or syntax, but is accessible to anyone with basic C++ knowledge or programming experience. Even the most experienced C++ programmer though will learn a thing or two from it and find it a useful memory-aid. Among the topics covered are:

• The essentials that the C++ Standard Library has to offer
• How to use containers to efficiently store and retrieve your data
• How to use algorithms to inspect and manipulate your data
• How lambda expressions allow for elegant use of algorithms
• What the standard string class provides and how to use it
• How to write localized applications
• What functionality the library provides for file and stream-based I/O
• What smart pointers are and how to use them to prevent memory leaks
• How to write safe and efficient multi-threaded code using the C++11 threading libraries

Final features of C++17

By Meeting C++ | Jul 1, 2016 02:07 AM | Tags: standardization experimental c++17 advanced

A short overview over the latest highlights from Oulu

Final features of C++17

by Jens Weller

From the article:

With last weeks C++ committee meeting in Oulu, C++17 is feature complete and on its way to become an international standard...

Trip report: Summer ISO C++ standards meeting (Oulu) -- Herb Sutter

By Blog Staff | Jun 30, 2016 04:17 PM | Tags: None

A comprehensive trip report from the just-concluded ISO C++ meeting:

Trip report: Summer ISO C++ standards meeting (Oulu)

by Herb Sutter

From the article:

The big news is that C++ is feature-complete, and on time! We added several more features to the C++17 working paper (see next section), then approved the result to be sent out this summer for its major ISO international comment ballot, which is the Committee Draft or “CD” ballot.

... At this meeting, we added several more features into C++17: ...

Competing constructors--Andrzej Krzemieński

By Adrien Hamelin | Jun 30, 2016 01:15 PM | Tags: None

We all got some surprises like this:

Competing constructors

By Andrzej Krzemieński

From the article:

We start with a known C++ gotcha:

std::vector<int> v (size_t(4), 2); // parentheses
std::vector<int> u {size_t(4), 2}; // braces
 
assert (v.size() == 4);
assert (u.size() == 2);
 
assert (v[0] == 2); // elements: {2, 2, 2, 2}
assert (u[0] == 4); // elements: {4, 2}

In this post I want to analyze the source of the problem a bit further, and offer some suggestions on class design.

Quick Q: Are `==` and `!=` mutually dependent?

By Adrien Hamelin | Jun 29, 2016 01:42 PM | Tags: basics

Quick A: They are not, because it is not always true.

Recently on SO:

Are `==` and `!=` mutually dependent?

You would not want the language to automatically rewrite a != b as !(a == b) when a == b returns something other than a bool. And there are a few reasons why you might make it do that.

You may have expression builder objects, where a == b doesn't and isn't intended to perform any comparison, but simply builds some expression node representing a == b.

You may have lazy evaluation, where a == b doesn't and isn't intended to perform any comparison directly, but instead returns some kind of lazy<bool> that can be converted to bool implicitly or explicitly at some later time to actually perform the comparison. Possibly combined with the expression builder objects to allow complete expression optimisation before evaluation.

You may have some custom optional<T> template class, where given optional variables t and u, you want to allow t == u, but make it return optional<bool>.

There's probably more that I didn't think of. And even though in these examples the operation a == b and a != b do both make sense, still a != b isn't the same thing as !(a == b), so separate definitions are needed.

Typedef Literacy--Michael Park

By Adrien Hamelin | Jun 29, 2016 01:38 PM | Tags: basics

typedef explained!

Typedef Literacy

by Michael Park

From the article:

The typedef declaration provides a way to create an alias for an existing type. For example, we can provide an alias for int called integer like so:

typedef int integer;

I imagine most people have seen such declarations, and they are fairly simple to read. In fact it’s so simple that we may incorrectly conclude that the syntax for typedef is:

typedef <existing_type> <new_type_name>;

Quick Q: Why doesn't std::queue::pop return value?

By Adrien Hamelin | Jun 27, 2016 01:52 PM | Tags: intermediate efficiency

Quick A: To guarantee exception safety and for performance.

Some time ago on SO:

Why doesn't std::queue::pop return value?

So, whats the difference, pop function could have done the same thing.

It could indeed have done the same thing. The reason it didn't, is because a pop that returned the popped element is unsafe in the presence of exceptions (having to return by value and thus creating a copy).

Consider this scenario (with a naive/made up pop implementation, to ilustrate my point):

template<class T>
class queue {
    T* elements;
    std::size_t top_position;
    // stuff here
    T pop()
    {
        auto x = elements[top_position];
        // TODO: call destructor for elements[top_position] here
        --top_position;  // alter queue state here
        return x;        // calls T(const T&) which may throw
    }

If the copy constructor of T throws on return, you have already altered the state of the queue (top_position in my naive implementation) and the element is removed from the queue (and not returned). For all intents and purposes (no matter how you catch the exception in client code) the element at the top of the queue is lost.

This implementation is also inefficient in the case when you do not need the popped value (i.e. it creates a copy of the element that nobody will use).

This can be implemented safely and efficiently, with two separate operations (void pop and const T& front()).

Jon Kalb speaks about CppCon, C++17 standard and C++ community--Anastasia Kazakova

By Adrien Hamelin | Jun 22, 2016 12:12 PM | Tags: None

Here is an interesting read:

Jon Kalb speaks about CppCon, C++17 standard and C++ community

by Anastasia Kazakova

From the article:

Here comes another interview in our blog. This time we speak with Jon Kalb, CppCon Chair and C++ instructor.

Modern C++ Features – constexpr--Arne Mertz

By Adrien Hamelin | Jun 17, 2016 02:16 PM | Tags: intermediate c++14

The last of the compile time constant series.

Modern C++ Features – constexpr

by Arne Mertz

From the article:

In the last two weeks I have written about the basics of compile time constants and calculation with those constants. This week I conclude this mini series with the keyword constexpr added in C++11/14...

Enabling forward traversal -- Krzysztof Ostrowski

By fj | Jun 16, 2016 11:31 PM | Tags: None

Krzysztof Ostrowski describes in his article enabling iteration over a sequence of objects of given type without changing the type name itself.

Enabling forward traversal

by Krzysztof Ostrowski

From the article:

Let's consider following example. We have legacy interface that constructs object of type T using information stored in object of type U:

bool build_from(T& into, const U& from);

Such a build_from can be deserialiser function, e.g. from JSON to C++ type, for example:

result_type deserialise(T& into, const json_node_type& from);

Ideally, we should return into rather than taking it as an input argument, i.e. return optional<T> or type that carries information about the errors too, like C++ counterpart of Either. Unfortunately, we have to deal with legacy interafce, so that existing contracts cannot be broken, and our patch sets shall favour composition and extension over the modification.

With deserialise we know how to convert internal JSON representation into object of type T. That works fine for non-structured types. JSON offers associative containers (dictionaries, hashes, structures as defined in YAML) and collections. Dictionaries map easily to product types, struct in C++, and for those we typically need custom deserialisation procedures. Collections may be seen as abstractions over structures, or – more functionally – as sequenced values of type T for collection of type [T]. Since we know how to deserialise objects of type T, we can deserialise [T] by simply mapping deserialise over a sequence of T objects, that is doing forward traversal. Unfortunately we have just one JSON node from, not a sequence of nodes. We need to enable forward traversal for the type json_node_type with minimal number of changes.