I’m reading through Bjarne Stroustrup’s Tour of C++, which Addison-Wesley have graciously allowed him to post ahead of its inclusion in the fourth edition of The C++ Programming Language.
It starts with The Basics. It was refreshing to see new features of C++11 introduced alongside the most rudimentary aspects of the language – rather than being viewed as a whole new language that teams might choose to adopt/ignore. I’m sure if you start learning C++ today, features such as enum class, auto, constexpr will seem natural, begging the question “What did you do without them?”.
I thought this code snippet was especially cute:
for (auto x : {10,21,32,43,54,65})
std::cout << x << '\n';
I’m used to writing code in F# like this,
[| 10; 21; 32; 43; 54; 65 |]
|> Array.iter (fun i -> printf "%d\n" i)
but it’s great to see such concise code in C++ at well.
The second part concerns abstractions. This includes summaries of copy and move semantics. This note on move semantics is helpful because many explanations focus on how to move data into a new instance of a class rather than the state in which to leave the old object:
After a move, an object should be in a state that allows a destructor to be run. Typi- cally, we should also allow assignment to a moved-from object
Preventing copy and move:
Using the default copy or move for a class in a hierarchy is typically a disaster: Given only a pointer to a base, we simply don’t know what members the derived class has (§3.3.3), so we can’t know how to copy them. So, the best thing to do is usually to delete the default copy and move operations; that is, to eliminate to default definitions of those two operations
where C++11 provides the delete annotation to tell the compiler not to write a default copy/move operation, but you could follow today’s practice and declare it private and omit the implementation until your compiler catches up.
If you need to copy an object in a class hierarchy, write some kind of clone function. [Note that] a move operation is not implicitly generated for a class where the user has explicitly declared a destructor. Furthermore, the generation of copy operations are deprecated in this case. This can be a good reason to explicitly define a destructor even where the compiler would have implicitly provided one.
There are also useful examples of where to use type aliasing, for example this one that uses the assumption that STL containers provide a value_type alias (or typedef):
template<typename C>
using Element_type = typename C::value_type;
template<typename Container> void algo(Container& c)
{
Vector<Element_type<Container>> vec;
// ...
}
You can also use aliasing to define new templates by binding arguments on existing templates:
template<typename Value>
using String_map = Map<string,Value>;
String_map<int>m; //alias for Map<string,int>
Part three is about algorithms and containers.
The example for how to write operator>>(), read from, is particularly verbose – I’m sure it would have been better to show a regex solution alongside. Worth a look anyway for this mechanism for indicating a streaming failure (typically I would throw an exception):
is.setf(ios_base::failbit);
Similarly, I hadn’t realised before that range-checked random access to a std::vector was possible via the at(size_t i) method:
T& operator[](int i) { return vector::at(i); } // range-checked
The final part is about concurrency and utilities.
One of the main utilities now available in C++11 is std::shared_ptr (which was sorely lacking from the previous standard). However, Stroustrup hints that in many cases it’s sufficient to create an object on the stack with a local variable:
Unfortunately, overuse of new (and of pointers and references) seems to be an increasing problem.
When you do need to manage heap objects, std::unique_ptr is very lightweight with no space or time overhead compared to a built-in pointer. You can pass or return unique_ptr’s in or out of functions, because the implementation uses move semantics (whereas std::shared_ptr is copied).
One concurrency topic that always causes problems is how to define a convention between locks so that deadlock cannot occur due to acquiring the locks in the wrong order. There’s a neat example of how to avoid that:
// Initialise lock guards with their mutexes, but don't lock yet
std::lock_guard<std::mutex> lock1(mutex1, defer_lock);
std::lock_guard<std::mutex> lock2(mutex2, defer_lock);
std::lock_guard<std::mutex> lock3(mutex3, defer_lock);
// other preparation
std::lock( lock1, lock2, lock3 );
// Implicitly release all mutexes when locks go out of scope.
Stroustrup also introduces the concepts of futures and promises:
The important point about future and promise is that they enable a transfer of a value between two tasks without explicit use of a lock; “the system” implements the transfer efficiently.
The absence of locks is key and is also mentioned when introducing std::packaged_task and std::async. This section might be better written in reverse, with the simpler async concept introduced first and locks/mutexes in context as the advanced technique.
Under <utilities>, a boon is likely to be std::tuple, a heterogenous sequence of elements (I’ve added the use of std::tie to show how to unpack the values):
auto myTuple = std::make_tuple(std::string("Hello"), 10, 1.23);
std::string a;
int b;
double c;
std::tie( a, b, c ) = myTuple;
I wouldn’t use std::tuple in an externally visible interface, but it’s useful to avoid defining types for passing multiple return values.
I like this example of using the new standard <random> library to simulate a die:
using my_engine = default_random_engine; // type of engine
using my_distribution = uniform_int_distribution<>;
my_engine re {}; // the default engine
my_distribution one_to_six {1,6};
auto dice = bind(one_to_six,re); // make a generator
int x = dice(); // roll the dice: x becomes a value in [1:6]
musingstudio 