On 4/17/2012 3:47, Invisible wrote:
> 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.

This explains it better.

http://yosefk.com/c++fqa/inline.html

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

Right. Except in very limited circumstances when you know how deeply you'll 
recurse, because there's no guarantee it'll work and no way to check.

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

As long as you never make a mistake, yes. If you pass the wrong type, the 
wrong number, or do something with a bad pointer that makes you clobber the 
stack, it's helpful to know how it works. ;-)

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

What's questionable about that? Heck, on the Sigma 9, the registers 0 thru 
15 were actually addressed as memory locations 0 thru 15, to the point where 
you could store program code in the registers and branch to it.

> "They take care of internal housekeeping."
> ...actually...

Program Status Word.

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

Yep. Anything with memory mapping hardware, segment registers, etc.

> Still, it does answer something I've always wondered about: What *is* the C
> calling convention?

Undefined, generally speaking. Or rather, implementation-specific. And 
depends on pragmas, sometimes.

-
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message