jacob said:
Why shouldn't I? I mean using windowed output is quite normal this
days.
If you write to "stdout", the output will be whatever is "normal" for
the implementation.
You are at page 2. Do not be surprised if I haven't explained
EVERYTHING
Read ON!
This isn't merely an incomplete explanation, it's a wrong explanation.
You should focus on what data is, not examples of how data can be created.
Of course it is unnecessary. I just wanted to show an example of a cast,
and what it does. There is an explicit reference to a more detailed
explanation later.
But would it not be more education to use a cast which *is* necessary?
Otherwise you have users saying "what's the point?" -- or worse, users
who don't realise that it is unnecessary!
If you read two sentence before the table you will see:
"The implementation of the C language by the lcc-win compiler..."
You should still explain what standard C requires if you want to claim
this is an introduction to standard C. At the very least you should make
it clear that these sizes may vary on different implementations.
In this implementation (and many others) yes.
The point is that it is more harmful that helpful to think of pointers
as integers. (And that machine addresses are not necessarily just
integers, regardless of how many implementations you find where they are.)
Well... that's a union dear.
No, it isn't. That suggests that this code:
union {
int i;
long l;
double d;
} onion;
int main(void) {
onion.i = 1;
onion.l = 2;
onion.d = 3.0;
printf("onion.i is %d\n",onion.i);
printf("onion.i is %ld\n",onion.l);
printf("onion.i is %f\n",onion.d);
return 0;
}
will output
onion.i is 1
onion.l is 2
onion.d is 3.0000000
The problem is that I'm not accessing the variables simultaneously, but
I am *using* them simultaneously. There's an important difference.
You *cannot* store multiple values in a union simultaneously. I'm sure
you know this, but your language is sloppy and confusing.
The mentioning of the sign bit makes the whole thing easier to
understand
I disagree. A signed value can be negative. An unsigned value cannot.
What is hard to understand about that?
Yes.
It is very convenient. The lcc compiler does that.
It's terrible practice.
Yes. It is a hash function that works, but it is surely not the best and
it is not advertised as the best.
No, but it is advertised as a hash function which will do. If it will do
for an example, a user will expect it to do for his code. When he thinks
about hash functions, he will remember the one you provided and
copy/paste it in. (And why shouldn't he? After all, reinventing the
wheel is bad.)
n1256, 6.10.8p2:
The following macro names are conditionally defined by the implementation:
__STDC_IEC_559__ The integer constant 1, intended to indicate
conformance to the specifications in annex F (IEC 60559 floating-point
arithmetic).
If the implementation does not define __STDC_IEC_559__, it is only
constrained by the lower limits specified in 5.2.4.2.2.
Yes, it is the windows programming part!
Look again. Windows programming is in Chapter 3. There is no chapter 2.
(Though the contents do reference it.)
I think that you have obviously a bias against me. But your comments
are welcome. I will go on working in this.
Show me an example of bias and I will accept it. I think my comments
have been fair.
