On 16/04/2012 09:11 PM, Orchid Win7 v1 wrote:

> Day 5
>
> We are now on page 108, and that's where I stopped reading.

OK. So the book bothers to go to all the trouble of explaining what an 
inline function is, and why that's good. And in the next sentence, it says:

   "Note that inline functions can bring a heavy cost. If the function 
is called 10 times, the inline code is copied into the calling functions 
each of those 10 times. The tiny improvement in speed you might achieve 
is more than swamped by the increase in the size of the executable 
program. Even the speed increase might be illusory. First, today's 
optimizing compilers do a terrific job on their own, and declaring a 
function inline almost never results in a big gain. More important, the 
increased size brings its own performance cost."

In other words "now that we've explained how to use this feature, you 
should never, ever use it". Great. Thanks for that...

Now, I'm used to programming languages where the decision to inline 
something or not is down to the compiler. It's not something an 
application programmer would ever have to worry about. And it seems that 
the inline directive is only a "hint" in C++ anyway, so I have to 
wonder, whether this particular directive is now obsolete.



The book has this to say on the subject of recursion:

   "Both types of recursion, direct and indirect, come in two varieties: 
those that eventually end and produce an answer, and those that never 
end and produce a runtime failure. Programmers think that the latter is 
quite funny (when it happens to somebody else)."

Um... WTF?

Anyway, this is followed by an O(n^2) time Fibonacci function. I kid you 
not. Because, let's face it, obscure mathematical problems with no 
connection to reality are the only reason anybody would ever use 
recursion, right? :-D

I love the dire warnings that you could use a number less than 15, 
because otherwise the program might consume a vast amount of memory. 
(For goodness' sake, how much RAM does 15 stack frames take up?!)

"Some compilers have difficulty with the use of operators in a cout 
statement. If you receive a warning on line 28, place parentheses around 
the subtraction operation."

I'm going to go out on a limb and guess that this stopped being a 
problem ten years ago. :-P

Anyway, like the previous segment, we wrap up with

   "Recursion is not used often in C++ programming, but it can be a 
powerful and elegant tool for certain needs. Recursion is a tricky part 
of advanced programming. It is presented here because it can be useful 
to understand the fundamentals of how it works, but don't worry too much 
if you don't fully understand all the details."

In other words, yet again, "now you know how this works, you don't need 
to actually use it".



Now we get a tale about how function calling works.

   "Most introductory books don't try to answer these questions, but 
without understanding this information, you'll find that programming 
remains a fuzzy mystery."

Uh... yeah, whatever.

   "Few programmers bother with any level of detail below the idea of 
values in RAM. [...] You do need to understand how memory is organized, 
however. Without a reasonably strong mental picture of where your 
variables are when they are created and how values are passed among 
functions, it will all remain an unmanageable mystery."

I'm not sure what's so "unmanageable" about it all. Provided you don't 
try to reach behind the abstraction, there's no particular need to 
understand how it works. Then again, this is a low-level language, and 
if you're bothering to code in it, that probably means that you're 
intending to go behind the abstractions at some point...

   "As a C++ programmer, you'll often be concerned with the global name 
space, the free store, the registers, the code space, and the stack."

OK.

   "Registers are a special area of memory built right into the CPU."

Erm...

   "They take care of internal housekeeping."

...actually...

   "A lot of what goes on in the registers is beyond the scope of this 
book, but what we are concerned with is the set of registers responsible 
for pointing, at any given moment, to the next line of code. We'll call 
these registers, together, the instruction pointer."

So I'm guessing an architecture exists where the instruction pointer 
/isn't/ a single register then? :-P

I'm loving how they have to explain the idea of a stack using a crude 
drawing of a smiling, happy man putting a plate onto the top of a stack 
of plates. Because saying that in a sentence just doesn't bring it home, 
does it?

I'm looking at the description of function calls now. I'm loving how in 
step #3, the base address of the function is loaded into the instruction 
pointer, and then in step #5 the function's arguments are pushed onto 
the stack. Are you /sure/ it happens in that order??

Still, it does answer something I've always wondered about: What *is* 
the C calling convention? Apparently it's to pass all function arguments 
and function results via the stack, and also to store all local 
variables on the stack. (By contrast, if you're coding in assembly, 
usually you pass everything in registers. Apparently C doesn't do this.)


Ho hum. On to day 6, where hopefully I'm going to start learning 
something useful...

Post a reply to this message