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

Save to:
Instapaper Pocket Readability

Part 3 of Bjarne Stroustrup's draft Tour of C++ is now available. This material is a preview draft of Chapter 4 of Stroustrup's upcoming The C++ Programming Language, 4th Edition.

A Tour of C++, Part 3: Containers and Algorithms

by Bjarne Stroustrup

Stroustrup writes:

No significant program is written in just a bare programming language,
it would be too tedious.

However, just about any task can be rendered simple by the use of good libraries.

This third chapter of my tour of C++ begins the presentation of the standard library, which is about half of the C++ standard.

Constructive comments would be most welcome.

Add a Comment

You must sign in or register to add a comment.

Comments (14)

0 0

Bjarne Stroustrup said on Dec 11, 2012 10:09 AM:

I do listen and I do fix the problems mentioned, but I'm incredibly busy completing the book, looking at issues for future issues for C++, and doing the research and teaching for my university so that I cannot promise to update what I have already posted, and I can certainly not promise to update frequently and promptly.
1 1

matt said on Jan 9, 2013 09:00 AM:

"For simplicity, I will rarely use the std:: prefix explicitly in examples."

I'm somewhat ambivalent about this. Take an example a page later, auto addr = compose("dmr","bell−");

Here, it's obvious that "compose" doesn't come from the standard library (since the "compose" function is defined right there, just before its use), but in general the std:: prefix helps to distinguish between standard library (std::) / core language (no prefix) / user-defined (lib-maintainer/dev-chosen-prefix::) names at a quick glance.

It might be especially helpful for the beginners who are still trying to learn what the standard library offers (and thus won't be able to tell whether "compose" is a user-defined function or something from the standard C++).

Another related issue -- in principle, isn't "using namespace std" supposed to be reserved for porting legacy C (/pre-standard C++) code?
1 1

FaTony said on Jan 9, 2013 05:24 PM:

@matt, Absolutely agree. I always explicitly prefix standard library stuff with std::. In fact, I've grown so accustomed to it that even obvious classes and functions without prefix get me wondering for a few seconds where the hell they come from.
0 0

Muscles said on Jan 9, 2013 06:43 PM:

In section 4.3.4, your output operator example for the Entry struct has an extra \\", so it will output

{"hello", 42"}

You do not want the quote mark after the number.
1 0

Bjarne Stroustrup said on Jan 10, 2013 07:40 AM:

(1) std:: Tastes vary and I did no think adding something like 5,000 occurences of std:: would increase readability of the book code
(2) correction: Thanks1
0 0

Sebastian G. said on Jan 10, 2013 12:17 PM:

Nice! Just a quick reminder: You havn't yet updated the previous chapter's PDF. It seems to be still the first version. At least in 3.4.3 there is still an issue of undefined behaviour due to a dangling reference member in Less_than<>. Feel free to delete this paragraph.


A comment on library types, Vec<> and bounds checking: In my humble opinion, it's worth mentioning that at least two of the most popular C++ compilers offer an "STL debug mode" which helps during development. I realize that this is vendor-specific and not really a "pure C++" topic, but you could say something like "you may want to consult your compiler's / standard library's documentation to see whether it offers a debug mode that includes checked iterators and/or bounds checking" or something like this.
1 0

Arthur said on Jan 12, 2013 10:24 AM:

#matt & #FaTony
I believe guys that you're missing the point. The point of those examples is most of all to teach certain techniques and usage of certain classes, not to teach how to use classes from certain namespace(s).
I can compare it to someone drawing us a sketch of a certain part of landscape in order to explain to us how to get from where we are now, to the place where we want to be. Surely the scale won't match, nor there will be any _unnecessary_ details included, like fences, hedges and road signs. Why? Because the whole purpose of this sketch is to show us the general road layout so we can easily navigate and find our direction. If this sketch on the other hand contained all those details and more, like trees, birds nests etc. it would simply lost its readability and usability to us. Because what we want to now, is how to get from here to the place we want to go to, not how many trees are there, nor what type of fences are farmers using in this area.
Also Mr Bjarne also explains that:
"It is generally in poor taste to dump every name from a namespace into the global namespace. However, **in this book**, I use the standard library almost exclusively and it is good to know what it offers.
0 0

matt said on Jan 12, 2013 10:35 AM:

@Arthur: "it would simply lost its readability and usability to us."

Yeah, I actually agree with you on the big picture principle -- and that's my point, it's actually omitting the prefix that contributes (in my opinion) to "lost readability and usability." It's easier to read examples when you can just skim over without having to wonder whether something is from the core language, standard library, or user-defined (so you, the reader, can focus on "certain techniques and usage of certain classes" instead -- precisely!).

Anyway, as Bjarne said, tastes vary.
1 0

Arthur said on Jan 12, 2013 11:23 AM:

"It's easier to read examples when you can just skim over without having to wonder whether something is from the core language, standard library, or user-defined..."

And Mr Bjarne says:
"However, **in this book**, I use the standard library almost exclusively[...]"

And again, the whole purpose is not to show you what classes are in which namespace ( as in the sketch analogy: how many trees are on the right side while you are driving to your destination point), but how to use those classes and what techniques exist and how to use them (the rough road layout - that's all you really need - anything else would be unnecessary distraction).
1 0

matt said on Jan 12, 2013 11:54 AM:

@Arthur: I think you may have a wrong impression of my suggestion, perhaps I haven't stated it clearly enough. My point is not emphasizing "std::" as opposed to, say "boost::" (since, as you've noticed, "the standard library [is used] almost exclusively" in the book -- not that would be a bad thing, quite the contrary, but in this context this is off-topic), but "std::" as opposed to a lack of prefix for core language and user-defined functions (which are also *commonly* used in the book). If you take a look at the actual document (beyond the single sentence you seem to be focusing on), you'd notice that core language and user-defined fn. names appear on virtually every single page. For instance: "compose", "respond", "get_number", "has_c", "test", or "find_all" -- notice I've even omitted names like "m2", "m3", or "Greater_than", which would either be unusual in the standard library or don't follow its naming conventions anyway, and are thus harder to be confused with anything -- on the other hand, "find_all" could easily be a name from the standard library.

Again, in my opinion not having to think about "what classes are in which namespace" is precisely conducive to eliminating "unnecessary distraction." IMHO, "using namespace std" is falls exactly into the "anything else" basket that distracts from the big picture.

Ultimately though, as Prof. Stroustrup said, tastes vary, and he's the author, so this is just me offering a comment as a feedback from my perspective and deferring to whatever the final decision is.
1 0

Arthur said on Jan 12, 2013 12:23 PM:

"Again, in my opinion not having to think about "what classes are in which namespace[...]"

That is exactly why those examples are in the style they are - so you don't have to think/read about which class is in which namespace etc, but concentrate on classes, techniques and usage of thereof. Don't think about namespaces, think about techniques presented and how to make best use of them. Exactly for the same reason #include is also not mentioned everywhere - because it would be distracting and is unnecessary to demonstrate certain "technique".

4 0

Zenju said on Jan 14, 2013 05:24 AM:

> A comment on library types, Vec<> and bounds checking
I would cut this example entirely for at least two reasons:
1. overwriting a non-virtual method (operator[]) in a base-class is "dubious" from a design perspective (Meyers Effective C++ has a good rationale)
2. Beginners, which I assume are the target audience of the book, primarily should learn how the C++ library works, not how to workaround its design inconsistencies. E.g. vector<>::operator[] is implemented in terms of design by contract and has vector<>::size() as prerequisite, while map<>::operator[] is a "get and create" function with a misleading "name".
Beginners should not be encouraged to solve these kinds of problems right from the start, before the book had the time to explain how to do it right.

I know this is kind of a chicken and egg problem. But at least some examples (also in chapter 2) are poor from a modern C++ design standpoint, which undoubltly is due to the fact, that a better solution would have needed language features and design rationale not yet introduced at this specific time (e.g. the swap idiom). I just have the gut-feeling that for these examples (e.g. implementation of the assignment operator) it should be mentioned that there are better coding styles available (e.g. copy-construct + swap). Without such a "caveat emptor" it looks like these are all canonical examples, which they are not.
1 1

Ben Hanson said on Jan 14, 2013 10:04 AM:

What style suits a beginner is an interesting question. I remember learning C and C++ from books by Herbert Schildt when I was at University. As much as I may shake my head is disbelief now, I certainly found them useful at the time.

I also remember thinking K&R was too "old fashioned" at the time. Ah, the follies of youth! Looked at from that perspective maybe decisions on what is suitable for beginners looks rather different, but otherwise I agree with matt and Zenju.
0 0

Bjarne Stroustrup said on Jan 14, 2013 09:15 PM:

> Zenju said on Jan 14, 2013 05:25 AM

We don't seem to have the same idea of what "modern C++" is or how to teach it.

My suggestions as to how to teach it is basically "Programming: Principles and Practice Using C++". I do not think that focusing on getting novices to use libraries will make them into programmers.

To my eyes, your suggestions for what is good "modern C++ design" seem a bit dated.

Getting novices started and then up-to-speed is hard.