A shared view of C艹 (or, Around the C艹 world in 180 pages)

[Note: There has long been “one short and reasonably complete book you can assume everyone has read” for C -- K&R 2nd Edition (274 pages). But what is the “one short and reasonably complete book you can assume everyone has read” for C艹? Does a single short one even exist, and is it possible for one to exist? This post by Bjarne Stroustrup addresses that important question, with what we feel is the year's most important book on C艹 -- more important than even the C艹11-updated The C艹 Programming Language, 4th Ed., also by Stroustrup.

The "(or, Around the C艹 world in 180 pages)" alternate title for this blog post is our editorial suggestion, with apologies to both Stroustrup and Jules Verne. We believe this is quite appropriate for Stroustrup's year-end gift to the C艹 community. Enjoy. --Ed.]

 

For a graduate course in software design, I needed a few introductory lectures to “refresh” my students’ understanding of C艹. For The C艹 Programming Language (Fourth Edition), I wrote introductory chapters (about 80 pages) to give the reader an overview of C艹 before diving into the details. At the suggestion of Herb Sutter, I posted drafts of those four Tour of C艹 chapters on C艹.com, and at the suggestion of my Addison Wesley editor, Peter Gordon, I expanded these chapters to provide a comprehensive overview of and introduction to C艹 (for people who are already programmers, not complete novices):

A Tour of C艹

by Bjarne Stroustrup

Addison Wesley, ISBN 978-0321958310, 2013

In 180 pages, it covers the major C艹11 features and techniques plus most of the standard library. 180 pages is something most programmers can find the time to read. The tour (Tour++) benefited greatly from use and comments from many readers.

It gradually dawned on me that I just might have produced a solution to a decades-old problem for C艹:

What is the basic knowledge that we should be able to assume from a competent C艹 programmer?

Competent C programmers can be assumed to know roughly what is covered by K&R. Conversely, if they don’t -- or haven’t even heard of K&R -- it is a good guess that they can’t be relied on to contribute viable C code. I find that I cannot make an equivalent statement about C艹 programmers. Once upon a time, knowing TC艹PL (1st edition) served as a shared base, but that was a long time ago and C艹 has improved immensely since 1985. These days, there are functioning C艹 programmers who have learned all they know from the Qt documentation, from boost.org, from Scott Meyers’ many books, from some of my books and papers, from some of Herb Sutter’s books, etc., but don’t know more than one of these sources. Their ideas of what C艹 is are disjoint and incompatible. Many more programmers appear to base their understanding of C艹 on some ancient, outdated, and usually poor college textbook plus what they learn from on-line documentation and following some C艹 Q&A site. But you don’t become a good C艹 programmer just by knowing only the C艹 syntax and a multitude of library classes and functions. Similarly, being able to answer tricky “interview-style” questions about the ISO standard doesn’t make you a good C艹 Programmer.

We -- the huge and diverse C艹 communities -- do not share a body of basic understanding. This is bad; very bad! We don’t have a shared view of what good C艹 code is and we don’t communicate effectively. I find -- from web posting, from academic papers, from my email, and more -- that huge chunks of the last 20 years of progress in design technique, programming technique, and language support remain unknown and unused by many “C艹 programmers.” What a waste! More specifically, what a waste of energy as programmers suffer from outdated parochial views in their current work today! Conversely, what an opportunity for improvement!

Many have tried to address parts of this problem. The sources I mentioned above are not bad, but they are not shared and few are comprehensive. I can and do recommend them often. Further, I recommend the many superb talks from the “Going Native” 2012 and 2013 conferences (freely available on the Web) as well as talks recorded at Google, ACCU, and others. It is not volume of material we lack. On the contrary, it is quite easy to drown in information about C艹. Few practicing programmers can keep up with all the quality information being produced. Worse, the quality information is often drowned by the constant deluge of poor, outdated, and often wrong information provided on the web (and elsewhere).

As the risk of being seen as a blatant self-promoter, I would like to recommend A Tour of C艹. [We wholeheartedly support this recommendation. --Ed.] For a technical book, it is a quick read, and it is not a waste of time: I have never met a programmer of any experience level who didn’t learn something from reading it. If everyone read it, the C艹 community would again -- after something like 25 years -- have a common conceptual framework and vocabulary. Read it! You might even like it.

Add a Comment

Comments are closed.

Comments (20)

0 0

eider said on Dec 27, 2013 08:47 AM:

That sounds great!
0 0

Bjarne Stroustrup said on Dec 27, 2013 10:19 AM:

Maybe I have better state the obvious: Tour++ is not a simple copy of K&R for C艹. C and C艹 differ and the presentations must reflect those differences. C艹 is a larger language than C, so Tour++ must cover more language features, programming techniques, and libraries. This implies less detail. Also, I don't have my friend Brian's gift with words.

PS. K&R2 *is* a C艹 book; all the code is C艹, though in a very old style.
0 0

NoSenseEtAl said on Dec 28, 2013 08:40 PM:

I am profesional junior C艹 dev and honestly I dont see this great problem. I learn stuff from SO, isocpp... I use boost, RAII, smart ptrs, avoid crappy C艹 books/sites and honestly I would be very surprised to learn that there is a big part of C艹 im not aware of(note:aware of != proficient in smile ).
0 0

stereomatchingkiss said on Dec 29, 2013 07:52 AM:

Thanks for the book and all of your efforts on making C艹 become a better tool.I already study ch1~ch3, although the contents of this book is clean, easy to read, pick out a lot of important features and introduce us some good habit of programming. This book is like a guideline to show the C艹 programmers what are the most useful, important features of C艹 and what kind of programming skills you could implement by C艹 easily.But I wonder is this book suitable for a newbie who don't have any programming experiences(I studied primer, effectvie C艹 series, exceptional C艹 and other's C艹 book before I study "a tour of C艹")?

0 0

Alf P. Steinbach said on Dec 29, 2013 08:19 AM:

I like this book.

Things to consider for a second edition:

* "Smiley" derived from "Circle" gives slicing problem. Slicing should be discussed. And also the circle-versus-ellipse, that a mutable "Smiley" is not a mutable "Circle" (even if a "Smiley" value is a "Circle" value).

* The dicussion of "future" and "promise" doesn't quite reveal how to get a connected pair of "future" and "promise", except by way of a "packaged_task". I do not know enough about the C艹11 threading to say if there is any such more basic way, but if there isn't, then IMHO that should be stated in the text.

* I do not see any discussion of text and Unicode. That's understandable since even C艹11 is sadly lacking in this department (wstring etc. doesn't really cut it). But still, any international student will probably want to be able to output his or her name in a first or second program!

Again, I like this book, the above points are the three I decided now, after skimming the book, to focus -- so that the book's 2nd edition can be *EVEN BETTER* grin.
0 0

Bjarne Stroustrup said on Dec 29, 2013 09:02 AM:

Answers:
(1) anonymous poster #1: There is a massive problem with bad C艹 code "out there" even if you don't see it. Many programmers suffer from misconceptions writing seriously suboptimal code because of miscomprehension of C艹, such as "you have to write in C style to be efficient", "all code should be in member functions and all member functions should be virtual", "overloading must be avoided", "exceptions must not be used", and "for generality, every function should be a template." Sometimes, such miscomprehensions are enshrined in coding standards. The sad thing is that often such programmers think that they are using C艹 well.

(2) anonymous poster #2: For novices, I recommend "Programming: Principles and Practice using C艹. http://www.stroustrup.com/programming.html . Tour++ is for people who are already programmers.

(3) Alf: Thanks. It is hard to write about somewhat advanced topics without occasionally being obscure by referring to concepts that are not (yet) explained. I'll try to do better next time. Comments like yours with concrete examples are invaluable.
0 0

AndrewDover said on Dec 29, 2013 08:22 PM:

Some harmless typos from Chapter 1:

Page 6, yields, not yield
Page 13, read characters, not "rear characters"


I learnt that you can use the { initializers } in other than declarations:

 for (auto x : {10,21,32,43,54,65}) cout << x << '\n'; 


0 0

stereomatchingkiss said on Dec 29, 2013 10:39 PM:

a question of ch4

ch4 : the derived class of container--Vector_container do not provide a constructor with initializer_list.

class Vector_container : public Container { // Vector_container implements Container
Vector v;
public:
Vector_container(int s) : v(s) { } // Vector of s elements
~Vector_container() {}

double& operator[](int i) { return v[i]; }
int size() const { return v.size(); }
};

void g()
{
//Vector_container do not have a constructor which accept initializer_list
//how could it initialize like this?
Vector_container vc {10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0};
use(vc);
}
0 0

NoSenseEtAl said on Dec 30, 2013 01:01 AM:

@Bjarne
tnx for the A
I guess that was just my experience, but then again I never had problems with horrible bosses and people keep on telling horror stories smile, so I guess it was just a sampling error.
regarding not using exceptions - exceptions have good and bad sides, Alexandrescu mentioned this many times, and it is hard to call him a noobie smile
regarding C style code to be efficient - again gray area -ppl are often just ignorant and believe myths but I have met with ppl that work on crappy slow embeded HW and they cant afford heap allocations most of the time...
but great thing about C艹 is abstraction turbolift:
you can use in the same language tasks and inline asm(on certain compilers raspberry )/relaxed atomics/void* smile
1 0

Bjarne Stroustrup said on Dec 30, 2013 09:34 AM:

Thanks. It is easy to do "sampling errors" in the huge C艹 community.There are many more people who think that "virtual functions are evil" and many more people who think that "all functions should be virtual" than people who have heard of relaxed atomics.

It would be really nice, and really important, if we could get a shared base of understanding of C艹 - or even just a wide agreement that such a shared base would be useful.
0 0

NoSenseEtAl said on Dec 30, 2013 09:57 AM:

@Bjarne
I think it is a matter of something not related to C艹 specifically. Secret ingredient is scientific method. smile
People should learn to measure(like Alexandrescu says : 5ms might be fast or slow, compared to what) or get measurements from reliable sources(your list vector slide)
and learn that there are rarely a black/white decisions for all use cases(not to mention facts change, iirc there is one technical talk where Alexandrescu mentions that now reverse reading from memory is also very fast where before he would say fwd pass is preferred one).
Virtual functions have +s and -s depending on your design and performance requirements...you might want to say x% performance is not worth bothering with workarounds/redesign, but at least please have a good guess what x is. Ofc here things also change, iirc STL from MS said that VS implemented "devirtualizer" that if it can prove that your var must be of type X it will remove virtual function call.
Another classical is register keyword, iirc Stepanov says when he was implementing STL it gave him 3x speedup, now it is a cute language relict. smile
0 0

stereomatchingkiss said on Dec 30, 2013 11:08 AM:

>if we could get a shared base of understanding of C艹
Hope you could make this become reality one day.C艹 is too complicated, OOP, generic programming, procedural programming, TMP, FP, it support so many paradigms and each paradigm have different philosophy, use cases, some of the philosophy even contradict with each other's(just look at the OO world vs GP world or those who only fond of procedural programming).I am still trying to grasp the pros and cons of different paradigms and I wonder I would be able to master all of them(not to mention there are still many things to learn other than those paradigms).

In my world, some leader hate RAII totally and ask me don't use them(if I do, I may get fired since I do not obey the order); some team member think that C艹 is a pure OOP language build on top of c;someone think C艹 == c. In short, the codes in reality(at least in my environment) are far from the suggestions of your books(those C艹 gurus), and they think those "modern" style are evil.
0 0

Bjarne Stroustrup said on Dec 30, 2013 11:55 AM:

(1) stereomatchingkiss documents the problem nicely.

(2) "iirc Stepanov says when he was implementing STL it gave him 3x speedup, now it is a cute
language relict." I doubt it "register" was a relict before Stepanov designed the STL. "register" was useful until about 1984 (10 years before the STL) when the optimal register allocation algorithm was discovered and was quickly universally adopted.

0 0

stereomatchingkiss said on Dec 30, 2013 04:44 PM:

on chapter 4.3--Abstract types

The codes Vector_container do not provide a constructor with initializer_list

class Vector_container : public Container { // Vector_container implements Container
Vector v;
public:
Vector_container(int s) : v(s) { } // Vector of s elements
~Vector_container() {}

double& operator[](int i) { return v[i]; }
int size() const { return v.size(); }
};

but the following codes call the constructor like the initalizer_list ever exist

void g()
{
Vector_container vc {10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0};
use(vc);
}

The question is, how could the codes compile if it do not declare a constructor like this?

Vector_container(std::initializer_list<double> s);
0 0

Bjarne Stroustrup said on Dec 30, 2013 04:54 PM:

stereomatchingkiss on chapter 4.3--Abstract types ...

Yes, it's a bug. Fixed.
0 0

NoSenseEtAl said on Jan 2, 2014 12:43 AM:

@Bjarne
you can ask Stepanov, it was in his A9 lectures but they dont have transcripts so I cant find exactly what he said. Anyway like i said it was iirc, but im pretty sure he did a short story about that.
0 0

Bjarne Stroustrup said on Jan 4, 2014 08:06 AM:

Alex Stepanov just told me that he used "register" to good effect in 1987 (three years later than I guessed), but not for the STL (for the reason I gave).
0 0

NoSenseEtAl said on Jan 6, 2014 05:33 AM:

@Bjarne
good to know, like I said it was iirc, at least I wasnt 100% off.
Hopefully one day compilers will be smart enough to make std::move a relict also. smile
0 0

Bjarne Stroustrup said on Jan 6, 2014 07:28 AM:

NoSenseEtAl: "Hopefully one day compilers will be smart enough to make std::move a relict also."

It already is a relict in the most important case: returning a value (e.g. returning a vector)
0 0

NoSenseEtAl said on Jan 6, 2014 08:22 AM:

@Bjarne
True,
but there is 2 cases I at least would like to as-if compiler optimization magic:
1) passing a vec by value to a function and not using it later(and all the elements have a noop dtor) transformed into a move.
2) http://cpptruths.blogspot.com/2012/03/rvalue-references-in-constructor-when.html though pass by value solution seems nice I would be happy that compiler figures out possible optimizations by itself without programmer bothering with all the '&' & '&&'
Though again this is not to underestimate value of move in C艹11. It is a great feature. smile