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.

"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−labs.com");

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?

@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.

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) 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

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.

#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.

@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.

#matt
"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).

@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.

#matt
"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".

Regards

> 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.

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.

> 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.