On 4/17/2012 1:52, Invisible wrote:
> Except that assembly generally follows a simple and consistent syntax,

... says the man who never programmed in an assembly language for machines 
designed to be programmed in assembly language.

> an "obscure feature" which you don't need to know about. :-P

It *is* outside the C standard, tho, in terms of what it "means".

> I dislike code that's so littered with comments that you can't see the code

Except in assembler.

> That's pretty messed up.

Why is it messed up? Ada even has a type for "one byte of memory" and a 
different type for "one byte of I/O".  You might read 8-bit strings from an 
I/O channel into 9-bit memory.

>> One warning: sizeof() will return the size in char, not bytes.
> Oh, that's fun. Let us hope that char *is* one byte, otherwise... damn!

Nah. There's a header file that tells you how many bits per byte. I'm pretty 
sure C assumes binary computers, tho. :-)

> I guess this is why autoconf exists. :-P

That and amongst many, many, *many* other reasons. Note that C isn't a 
portable language. It just lets you stick many versions of the source code 
into one file.

>> Second warning: the signedness of char is local to the compiler.
>
> Really? The book seems to say that all integer types default to signed,
> unless you request unsigned. (AFAIK, there isn't a way to request signed.)

Except characters. Because PDP-11.

> So much for C and C++ being for system-level programming. :-P

It was never very *good* for it. It was just better than its competitors of 
the time.

> microcontroller, I might be worried. On a desktop PC, I'm not too concerned.

Now, yeah. Note that IEEE standardized floating point *long* after C was 
around. Heck, even after x86 was around IIRC.

>> Usually, float is a 32 bits, double is 64 bits. But it is known that
>> some compiler would perform the computation on 80 bits registers...
>
> Is there a way to explicitly request 80 bits?

No, of course not. C doesn't provide any way to ask for a type based on what 
you need. You can only ask for types based on what the CPU provides, and 
header files to tell you what the CPU provides so you can write code to try 
to compile the right version. In Ada, in contrast, you'd say "give me the 
float with X range and Y precision."

> Right. So if I request a 2GB array, it won't actually sit there trying to
> zero all 2GB of RAM, right before my for-loop rolls over it to initialise it
> /again/.

The OS probably will, tho, if you have a multi-user OS.

> So, it always rounds downwards?

It might depend on the sign. Two positive integers always rounds down.

> Oh that's sick. So comma really /is/ an operator? Wow, that's evil.

Why? It's just an operator. Is it really worse than Haskell's "." or ">==" 
operators, or whatever they're called?

> I was referring more to the fact that it's legal to not specify the return
> type, and if you don't, it defaults to something absurd.

It defaults to integer. Not sure what makes that "absurd".

>>> Next, we learn that function arguments can have default values. But get
>>> this:
>>>
>>> "Any or all of the function's parameters can be assigned default
>>> values. The one restriction is this: If any of the parameters does not
>>> have a default value, no previous parameter may have a default value."
>>>
>>> ...um, what?
>>
>> At one point in the argument list, you must start providing default
>> values, for all argument at the right of that point.
>
> ...which makes infinitely more sense than what the book said. :-P

Really!?  What the book said was clearly and simply a mathematical-type 
statement. No parameter without defaults can be preceeded by one with 
defaults. Hence all defaults must come after all non-defaults.

The previous statement is inaccurate in that it does not take into account 
no-defaults and all-defaults.

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