Hi there,
I'm a C++ Noob. I'm fairly competent with Javascript, Python and Java, but had never really gotten into C++.
So while I am traveling abroad this summer I decided to purchase 'Jumping into C++' to finally try and learn it. The digital format is definitely nice since I can keep it on my iPad and don't have to worry about a heavy book taking up space in my backpack.
I'm about half-way through the book and noticed a few things that are not explained well enough, or cases where the example code just wouldn't compile due to typos. I hope this will be useful to the author when they create the next edition.
Disclaimer: as I already mentioned, I am a total beginner when it comes to C++, so If something that I think is wrong is actually correct, please let me know. Also some of these comments are style-related, so just take them as suggestions.
Chapter 1
- Page 44: Style - Pronunciation inconsistency
When mentioning the cout object it says that it is pronounced "C out", while on page 50 (chapter 2) the cin object is said to be pronounced "see in". personally I like "C out" and "C in" better than "see out" and "see in" but it should be consistent one way or the other.
- Page 47: Style - State Farm Example
The state farm example seems fairly forced and awkward. It's also not accessible to people who don't know what state farm is (anyone not living in the US). Also I think the use of a youtube video is ill advised, since those can be taken down without notice, and then you'll have a broken link in the book.
Chapter 2
- Page 50: Style - Pronunciation inconsistency:
See Pronunciation style note above.
Chapter 5
- Page 74: Code - i not initialized
On line 1 of the example code near the bottom of the page:
Code:
int i; // variable declaration and initialization
while ( i < 10 ) ) // condition
...
Despite the comment saying that the variable has been initialized, it was only declared, and NOT initialized. The code may run since it will have a random value, but it also may not.
The code should be:
Code:
int i = 0; // variable declaration and initialization
while ( i < 10 ) ) // condition
...
Chapter 9
- Page 109: Inconsistency - Page 109: Refering to wrong Practice problem
Practice problem 3 mentions a guessing game "from part 1". Assuming this is referring to Practice problem 1 from that practice set it is incorrect. Problem 1 is the coin flip. The Guessing game is Problem 2.
Suggestion: change it to say "from problem 2"
- Page 117: Code - using 'I' instead of 'i'
On line 8 of the last example code on this page:
Code:
...
if ( array[ i ] < array[ index_of_smallest_value ] )
{
index_of_smallest_value = I;
}
...
It uses
I instead of
i, so the code would not compile since
I has not been defined.
The code should be:
Code:
...
index_of_smallest_value = i;
...
Chapter 11
- Page 126: Code - Practice Problem 4
Practice problem 4 asks what the output of a piece of code is. While the answer on
page 360 claims that the output is
A. 50 it should be
C. This code will not compile
In the following part of the code:
Code:
...
Struct MyStruct
{
int x;
};
...
The declaration for
Struct is capitalized, which causes an error for me in Xcode:
http://i.imgur.com/PNwWL.png
Thus, the correct answer is
C. This code will not compile, assuming Xcode's compiler behaves the same as those of windows/linux.
The answer should be changed to
C, or the capitalization of '
struct' fixed.
Chapter 13
- Page 135: Code - Not correctly creating a pointer 1
This one made me do a double take. In a section intended to introduce pointers to the reader, on the same page that shows how to declare a pointer we see this:
Code:
int x;
int p_x = & x;
*p_x = 2; // initialize x to 2
As I said, I'm a C++ Noob - Pointers are completely new to me - but my intuition screams to me saying 'WTF! This is not right!'
And my compiler agrees:
http://i.imgur.com/GClz8.png
- Page 136: Style - Barry Bonds reference
This is a minor nitpick, but similar to the state farm example, this really is not very accessible to people that don't care about baseball (ie. the rest of the world). I get that it's meant as a joke, but c'mon.
- Page 139: Code - Not correctly creating a pointer 2
On the first line of the last example code on this page:
Code:
int p_int = NULL;
...
It's the same issue as above. There is no pointer being declared, just an int. Here's the compiler output again:
http://i.imgur.com/nftbB.png
The chapter starts by saying how the reader might be afraid of pointers, and I can see why now.
- Page 139: Style - Sample Code 35: swap.cpp
The sample code shows the difference between two functions. When pointing out a difference between two similar bits of code it would be best for everything to be the same, except the one difference being highlighted.
For me personally the visual look of a chunk of code is very important, I am a very visual learner. I feel that it would be better to change swap1 to:
Code:
void swap1(int left, int right)
{
int temp = left;
left = right;
right = temp;
}
so that it mirrors the layout of swap2. Yes I realize this is a little OCD.
- Page 143: Code - Assigning a string to an int.
In the first part of the example code:
Code:
struct myBigStruct
{
int x[ 100 ]; // big struct with lots of memory!
};
We create a structure with an array of integers.
Then in the next part:
Code:
void takeStruct myBigStruct& my_struct)
{
my_struct.x[ 0 ] = "foo"
}
... we attempt to assign "foo" to an int.
Chapter 14
- Page 147: Style - position of asterisk in pointer declaration
So far pointers had only been mentioned as being declared in the following format:
it even tells us so on page 135.
But then all of a sudden it uses:
Code:
int numbers[ 8 ];
int* p_numbers = numbers
...
As a total beginner with using pointers this really caught me off guard. What is going on here, why is the '*' on the int? what does this new syntax mean?
As far as I can tell the book never goes into detail saying that both
int* ptr and
int *ptr are valid and just different styles. In fact I ended up spending about an hour trying to research online exactly what the difference between the two forms was.
I think it is important as an author to remember that when you are writing for total beginners, they are generally not confident with the new concepts. Every curveball you throw at them will set them back and confuse them. I know from personal experience that these 'curveballs', where something is not properly explained, or the author just assumes that you'll "get it", are part of the reason why I've always been discouraged from learning C++.
If anything a beginner often needs someone to say "yes, this is ok, don't worry about it".
- Page 148: Code - sample code 36, resize_array.cpp 1
This code compiles, but it is not correct. While '
next_element' is declared to keep track of how full the '
p_values' array is, it is never incremented.
As a result the code will never actually run the '
growArray' function, because it will always be assigning the value that the user inputs to position 0 of the '
p_values' array.
You can easily see this by including the following code:
Code:
cout << " the next element is currently: " << next_element + 1 << " of << size << '\n';
As shown here:
http://i.imgur.com/DVnUK.png
- Page 149: Style - sample code 36, resize_array.cpp 2
This is very much my own opinion, But I think there are a lot of things wrong with this example.
1. The user has no idea what is going on when the code runs
When introducing complicated new concepts to a reader make sure they can see what is going on - add more debug text.
I had the fortune of having a bit of programming experience and so my intuition told me that something was not working, but sample code 36 is just a giant black box with absolutely zero feedback to the user! Even if it all ran correctly there would be no way for the user to know, and a complete beginner would not know to try to look.
This is all the more important in this section of the book where the user does not know about debugging and breakpoints yet.
2. The code is incomplete
Assuming the
next_element value was actually incremented, then what? The array resize will only work once, since we are not changing the '
size' value.
Honestly, this whole example seems like it was started and never finished. It even contains the "// now all we need to do is implement growArray" comment in the final version, when clearly it's already implemented.
It has such potential to show the user a dynamically resizing array and it just doesn't do that.
I took about 5 minutes to write an edited version of this example. It may not fit the style of the book, but I think it does a much better job at explaining the concept to the reader in a way where they can actually see what is going on:
https://gist.github.com/6b3b2933996214d1ff42
It even has the bonus of re-inforcing the concept of pointers as function arguments by having the
growArray function also increment the
size integer variable.
And here is an example output from that code:
Code:
Please enter a number for element 0 of 1: 1
Please enter a number for element 1 of 1 (or 0 to exit): 2
- Array resized! was 2 long, is now 4 long.
Please enter a number for element 2 of 3 (or 0 to exit): 100
Please enter a number for element 3 of 3 (or 0 to exit): 5
- Array resized! was 4 long, is now 8 long.
Please enter a number for element 4 of 7 (or 0 to exit): 324
Please enter a number for element 5 of 7 (or 0 to exit): 892
Please enter a number for element 6 of 7 (or 0 to exit): 1337
Please enter a number for element 7 of 7 (or 0 to exit): 2
- Array resized! was 8 long, is now 16 long.
Please enter a number for element 8 of 15 (or 0 to exit):
I strongly feel that this does a -much- better job at actually teaching the reader something potentially useful. It's not perfect, and it might be better to use next_element+1 and size in the output, as well as a Do/While loop for the user input, but it gets the basic idea across.
3. It uses some confusing syntax
As mentioned in a previous style note, it's often good to say "yes, this is ok". in this case, this example was the first time showing a function that returns a pointer.
I personally wasn't sure if the int *function ( arg1, arg2, ... ) format meant something different than it just "it returns a pointer". To avoid the reader getting hung up on this it would have been very helpful if earlier in the section that had been mentioned along with a smaller example, perhaps even in chapter 13.
Summary (so far)
I really enjoyed this book for the most part, and feel it has a lot of potential to be an accessible way for beginners that have never used C++ before to learn it.
However I cannot stress enough how important the reader's confidence in what they are reading is. The absolute worst thing that can happen is for a user to type exactly what is written in the book, and it doesn't compile. That is how you frustrate and discourage readers and make them want to give up.
So my advice to the author: very closely inspect the example code, even the small bits in each chapter's body. It is definitely possible that I didn't look at all of the code, especially in the beginning few sections. At the very least run every big of code through the compiler to catch the most glaring mistakes.
Before I purchased the ebook I actually emailed the author, curious if there was a hard-cover version available. I'm somewhat glad now that it's not out yet, because with an ebook it is much easier to release fixed editions.
In any case, I will continue going through this book and will probably post again if I find any more mistakes or have any more feedback.
Originally Posted by Johannes
I'll admit that it's a bit of a nitpick in any case.
I'd fix them if I could.
