Home » Blog » 2013 » February » Stroustrup’s Tour of C++: Fourth chapter posted

Stroustrup’s Tour of C++: Fourth chapter posted

By Blog Staff | Feb 8, 2013 09:36 AM | Tags: basics

The final installment of Bjarne Stroustrup's four-part Tour of C++ is now available. This material is a preview draft of Chapter 5 of Stroustrup’s upcoming The C++ Programming Language, 4th Edition.

A Tour of C++, Part 4: Concurrency and Utilities

by Bjarne Stroustrup

Bjarne writes:

Describe all of C++ in 100 pages (or less). Don't just describe the language, include the standard library. Don't use "white lies" to simplify. Describe the major programming styles and techniques. Give rationale. Don't forget about concurrency. And, oh, by the way, make it readable to programmers (do not require a PhD).

That was the task I set myself when I decided to write the "Tour of C++" for TC++PL4. I suspect that succeeding perfectly is beyond me, but at least I met the first criteria: The tour is currently 98 pages, and shrinking.

This last, part 4, of the tour presents concurrency and some of the newer standard-library facilities.

Enjoy!

See the whole Tour here.

Add a Comment

Comments are closed.

Comments (10)

1 0

Muscles said on Feb 8, 2013 07:52 PM:

In section 5.3.4.1 page 126, you declare 


queue<Message> mqueue;


and in the consumer function you have


auto m=mqueue.top();


I'm not sure if some libraries provide top() as an alias for front() but it doesn't seem to be in the standard. top() would be appropriate for priority_queue().

Also, according to http://en.cppreference.com/w/cpp/thread/condition_variable/wait, wait can wakeup spuriously, so should you be testing for mqueue.empty()?
0 0

Zenju said on Feb 9, 2013 06:23 AM:

@Muscles: Yes and while nitpicking, the "mcond.notify_one();" should run *outside* the "unique_lock<mutex> lck {mmutex};" to avoid "premature pessimation" smile
And probably it's just me but when reading "auto dice = bind(uniform_int_distribution<>{1,6}, default_random_engine{});" I miss a remark about "default_random_engine{}" potentially being a perf-issue in tight loops.
0 0

Zenju said on Feb 9, 2013 06:28 AM:

Sorry, I can't resist to point out the strange design of having mutex as a public member associated with a class:

class Record {
public:
mutex rm;
// ...
};

Yes, concurrency is still new in the C++ library, but I think Herb Sutter's approach to this issue is more in the spirit of C++ (I hereby apologize for the sacrilege :D)
http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Herb-Sutter-Concurrency-and-Parallelism
0 0

David Irvine said on Feb 9, 2013 06:18 PM:

Just a quick typo on page 132, there is a ) where there should be a > in the template <class C) just after the "The real ‘‘type magic’’ is in the selection of helper functions:" statement.

Hopefully that buys credit for a question ? on page 120, where we need pointer semantics you list some cases, one you never mentioned and we come across in the office occasionally is inserting non default constructable objects into an stl container. I would be glad to hear your opinion on that (insert a ptr and then reset it to a value). It feels wrong but may be justified.

Great work on 11 and the book so far, looking forward to it in helping my fight against pointers and sharing (overuse that is, not in general) grin
0 0

Andy Prowl said on Feb 10, 2013 05:36 AM:

I'd like to point out a couple of things.

First, instructions like cout << ... are thread-safe by default since C++11, at least unless the client explicitly disables the synchronization. Thus, concurrent insertions into cout won't result in a crash, as stated at the end of 5.3.1 - although it is correct that concurrently printed output may interleave.

Second, a lock_guard<> cannot be constructed with defer_lock (see 5.3.4). That's possible only with unique_lock<>. AFAIK, a lock_guard<> is meant to be a lightweight RAII wrapper of mutex::lock()/mutex::unlock() which introduces no overhead. Knowing whether a mutex has or has not been acquired requires storing this information somewhere (i.e. at least an extra boolean flag, which is a minor memory overhead). Paragraph 30.4.2.1 of the C++11 Standard seems to confirm this.
0 0

robson said on Feb 10, 2013 05:48 AM:

In Section 5.3.4.1, page 125
high_resolution_clock doesn't have to use nanoseconds as its duration type, it can for example use duration<intmax_t, pico> and it is not possible to construct a value of type nanoseconds implicitly from some higher precision duration type, so you should use duration_cast<nanoseconds>().

In Section 5.6.3, page 137
in class Rand_int auto is used to declare a non static member variable, which is of course an error.
0 0

Bjarne Stroustrup said on Feb 10, 2013 08:45 AM:

Thanks for the input! I'll fix what I can. Annoyingly, several problems arose from an effort to abbreviate/simplify. For example, I originally used duration_cast, but people found the too-brief explanation confusing, so I postponed it to the presentation of chrono.

I'll have to think about the use case of using pointers to get non-default initializable types as container values. My first thought was "but why do they put default elements into the container in the first place?" (Yes, there are answers, but I see overuse of preallocation with values out of old habit with arrays).
0 0

David Irvine said on Feb 11, 2013 05:14 AM:

@Bjarne Thanks Bjarne I would be really interested in your opinion on this one.
0 0

Bjarne Stroustrup said on Feb 11, 2013 08:24 AM:

That was my answer (sort of grin. Any more detailed answer would depend on the answer to "but why do they put default elements into the container in the first place?"
0 0

David Irvine said on Feb 11, 2013 10:23 AM:

@Bjarne I get it grin Thanks Bjarne, very valid as ever. Already got the book on pre order for a few devs (especially me) so I won't hold you up.