On 4/17/2012 6:40, Warp wrote:
> and that sizeof(char) = 1 (which does not mean "1 byte", but "1 indexable
> memory unit".)

There are lots of RISC CPUs that only allow word-size transfers. But the C 
compiler generates code to do a load, mask, manipulate, merge, and write.

>> The book casually mentions something which /seems/ to be claiming that
>> variables are not initialised to anything in particular unless you
>> specifically request this. That's interesting; I didn't know that.
>
>    C hackers don't want the extra clock cycle to initialize a variable
> which will be immediately assigned a new value anyways.

Because, of course, the compiler can't reliably figure out if you're using 
it before you assign to it. ;-)

>    The former casts *anything* into a double, while the latter casts only
> compatible types. (Which means that the latter will give you a compiler
> error if you try to cast from an incompatible type by mistake.)

Because, as already explained, C++ is designed to make the compiler complain 
about questionable things you might have done accidentally. Like using a 
variable that you might not have assigned to. ;-)

>    If you define a variable (or function) in the global namespace, it will
> be visible in the entire program. (Yes, you can access it from a different
> compilation unit. You just need to declare it with "extern" in that other
> compilation unit to do that.)

I think you're mixing up scope and lifetime here. The variable is "visible" 
in the scope sense only below where you declared it. You can declare it 
anywhere and get to the same variable, sure. I'd call that "accessible" more 
than "visible" maybe?

>    (Also, from a design point of view, global variables decrease abstraction,
> which is bad.)

Meh. My rule is that a global is OK (especially in languages with actual 
namespaces) if you can define the meaning for the entire lifetime of the 
variable. The problem with most globals is that they usually only have 
meaningful values for a portion of the program's execution. But stdin being 
global? Yeah, no problem with that.

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