PDA

View Full Version : Jumping into C++ review - part 1



Johannes
07-15-2012, 07:36 AM
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:
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:

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:

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

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

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

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:


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:

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:

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:

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:

<type> *<ptr_name>
it even tells us so on page 135.
But then all of a sudden it uses:


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:

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:




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.

laserlight
07-15-2012, 07:49 AM
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.
I think that this is a usage inconsistency rather than a pronunciation inconsistency since the pronunciation of the letter "C" is the same as that of the word "see".

Alex, why not give some regulars a free copy of the ebook to proofread? :)

Johannes
07-15-2012, 08:02 AM
I think that this is a usage inconsistency rather than a pronunciation inconsistency since the pronunciation of the letter "C" is the same as that of the word "see".

Alex, why not give some regulars a free copy of the ebook to proofread? :)

Yeah, I wasn't really sure what I should call the header :tongue: I'll admit that it's a bit of a nitpick in any case.

And I think having people that know a lot more about the subject matter than me proofread it would be a fantastic idea!

Johannes
07-15-2012, 09:44 AM
Heh, looking back now I made a few mistakes myself (mostly leaving out a few semicolons here and there) but can't edit them anymore since it's past the 60 minute edit time, so please don't call me a hypocrite :wink: I'd fix them if I could.

Elysia
07-16-2012, 07:25 AM
I am skeptical at books whose authors do not properly compile the code they put in the book. Not having (yet) read this book, my current recommendation would be to trash it.
Btw, your fixed code is too aggressive. Consider what happens when next_element == 1. Remember that the initial size is 2, which means you have place for 2 elements.

Johannes
07-16-2012, 12:27 PM
I am skeptical at books whose authors do not properly compile the code they put in the book. Not having (yet) read this book, my current recommendation would be to trash it.
Btw, your fixed code is too aggressive. Consider what happens when next_element == 1. Remember that the initial size is 2, which means you have place for 2 elements.

While I appreciate the input, I took a lot of time here to try and help this author, so what you're saying is basically that I shouldn't have bothered with the effort and wasted my time, which feel is a little disrespectful.

I think that this ebook is more of an early draft than a final book, and hope that with mine and the community's input it can be improved. Had this been an actual real book that I bought, not a digital one, then I doubt I would have bothered.


Also thanks for the feedback, but analyzing my code there is really not the point - it's not my book. I was just giving a quick example I threw together in a few minutes to show the direction I would like the code to be taken in. I would certainly hope that the author does not to use my code verbatim, that would just be silly :p

phantomotap
07-16-2012, 12:27 PM
Not having (yet) read this book, my current recommendation would be to trash it.

O_o

If you intend to toss every book with errors you'd save yourself time by never picking up a book in the first place.

Soma

Elysia
07-16-2012, 12:29 PM
I know that. But I don't want to recommend books with lots of examples that do not compile. That, at least, a book should meet.

laserlight
07-16-2012, 12:35 PM
But I don't want to recommend books with lots of examples that do not compile.
I agree, hence my suggestion of free copies for forum regulars. After all, it is in our interest that Alex makes money from his book as it would encourage him to keep this message board going.

Johannes
07-16-2012, 12:39 PM
I agree, hence my suggestion of free copies for forum regulars. After all, it is in our interest that Alex makes money from his book as it would encourage him to keep this message board going.

Yeah, the fact that he's the guy behind this site also plays into my not just wanting to "toss" the book, and try to help the guy that has provided such a great resource for people.

whiteflags
07-16-2012, 12:48 PM
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.


People don't have car insurance in other parts of the world? Damn, people make fun of the lack of medical insurance coverage in the United States, but there is a total lack of car insurance elsewhere!?

:)

I'm not sure why Alex hasn't published errata, but let's hope he does. I normally don't agree with Elysia, but every book has mistakes and they need readily available explanations.

webmaster
07-17-2012, 03:15 AM
Hi Johannes, thanks for the corrections and suggestions! You have done an impressively thorough job of reading through the book, which should well serve you for learning C++. I've updated the manuscript based on your feedback.

If any forum regular is interested in a review copy, please send me a PM. I'd love to get your feedback.

Johannes
07-20-2012, 03:23 AM
Alex, I really appreciate the quick response, and that you will go back and fix some of these things! Do you know about when these changes will be reflected in the actual PDF? Will people be notified when a new 'revision' is released? Is there anywhere we can check for a change-log or something like that to keep track of when changes are made in the future?