As for the programming book for the scientifically inclined, it's the "scientifically inclined" part that scares me. I think if I was so inclined, my current book would be just fine for me, maybe I'm not so scientifically inclined and that book would be really difficult to understand?
I think the bottom line is that
any book is an extension of the author's own knowledge and learning style. If I were to write a book about programming I would base the flow of the book upon my own experiences and knowledge. I would try to guess how quickly I think you could learn a concept and provide just enough explanations to move things along at that pace. It might be that my pace is too slow for someone ("yeah, yeah, I get it, let's move on already") or too fast for someone else ("huh? how'd you get from point A to point B?")
That's why I advocate reading multiple books (or following up on book knowledge with a Google search, for example). Different people explain things in different ways, and reading multiple explanations can help you piece together the subtle things that one author might leave out but another author explains better.
I'm currently still in chapter 7. I've gone much slower lately and taken many days off because it was becoming too intense and I was staying up way too late banging my head against the wall. Unfortunately taking time away has made me forget some things that I knew pretty well before.
Maybe instead of following through one book, chapter by chapter, exercise by exercise, you should start coming up with practical projects that would help you exercise the skills you have already learned. Come up with a challenge for yourself, such as: "I want to write a simple text-based game", or "I want to write a program that will help me solve (a problem that I'm working on in my own life)" and work your way toward your own success. Instead of implementing the author's idea of an exercise program, and having you say "I don't get why he would ever want me to do that", if you are motivated by actually getting your own creation to work.
Start simple, and work your way bigger. Don't get too ambitious ("I want to write my own version of Angry Birds" is probably not a good beginner project).
All the new escape characters are confusing with regard to character constants. The sizeof operator makes no sense to me at all, nor do the related explicit conversion and implicit conversion operations. (can I call them operations or functions?) And, using the cast operator. Usual arithmetic conversions and conversion during assignment, and type definitions.
The problem for me is that while reading this I don't see the connection or usefulness based on what I learned already. These are such new concepts that I can't think of a situation when I'd want to use them.
I think part of the problem is that you're missing some background information that apparently the book isn't explaining. Knowing about character constants doesn't mean much if you aren't aware of, say, ASCII character representations (and
why you'd want to use them), or the various unprintable but useful characters such as newline, carriage return, linefeed, escape key, etc. -- admittedly somewhat antiquated now that we no longer tend to think of computers as typewriter-like devices.
Someone like myself might understand carriage returns because I remember using typewriters that literally had a carriage that returned to the beginning of the next line of paper, and my first printer was a dot-matrix printer that did much the same thing. I know about ASCII characters because I remember when computers booted up into DOS or some similar OS where the entire screen was a matrix of 80x24 "cells" that were
only capable of displaying one of X number of different characters -- represented by the ASCII set. So if I were to write a book, I might assume that everyone knows all about that, and forget to explain it...
Book: "Cast expressoins enable us to document type conversions that would take place anyway. " I know if they take place anyway, they are implicit, but what does it mean to "document type conversions that would take place anyway, and why do I need to do that"
Casting operations tells the compiler "treat this variable as if it were a ___". Otherwise it takes its best guess, but sometimes this can be wrong.
For example if you have an integer number of pizzas, and an integer number of people, you might want to calculate how to divide up the pizzas as follows:
int numberOfPeople = 6;
int numberOfPizzas = 3;
float pizzaFraction = numberOfPizzas / numberOfPeople;
printf("Everyone gets %f pizzas", pizzaFraction);
You'd expect that if you have 3 pizzas and 6 people, then each person gets 3/6 or 1/2 or 0.5 pizzas, right? You might therefore be surprised to find that the program says that nobody gets any pizza at all! What happened? You gave it two integers and asked it to divide, so the compiler assumes you want integer division. That means there are no fractions, and 3 divided by 6 is not an integer value, so the answer is 0. If you had used different numbers (say, 15 pizzas divided by 6 people) you would not get 2.5 pizzas per person, like you'd expect, but the integer value of 15 / 6, which is just 2. Either way the results are wrong.
If you wanted it to work right, you'd have to tell the compiler "I know these are integers, but I want you to treat them like floating point values when you do the math, because I do want fractional parts":
float pizzaFraction =
(float) numberOfPizzas / numberOfPeople;
The cast helps to fix the bug in this program, but it also serves to remind you that it's there for a reason, that you're asking the compiler to pay special attention here, which is what the book meant by "documenting" the type conversion.
There are many other uses for casting, too, especially when you get to pointers and structures, but this is the most basic use.
