What does this mean???

[CBFalconer]

Of course but these machines imaginary aren't they?

To the same extent that -1 is.

 

[CBFalconer]

Some of your alleged humour is on a par with your food. If I had
not responded an innocent passerby who didn't try to parse your
response, as I did, could be misled badly.

What humor? I think he is perfectly serious. Grammar counts.

 

[Joe Wright]

To the same extent that -1 is.

This is a very tough room. Let me try again. The question..
"what is meaned by " i = ~0 "..." might translate to..

int i = ~0;

...What goes on here?

The 0 of course in an integer value with all bits 0. The prefix tilde
performs a binary complement of the value, in this case to all bits 1.

The value of 'all bits 1' depends on how you look at it.

Two's complement suggests -1.
One's complement suggests -0.
Signed Magnitude maybe minus INT_MAX?

 

[Mark McIntyre]

Of course but these machines imaginary aren't they?

Well, certainly some of them are now extraterrestrial

http://en.wikipedia.org/wiki/Apollo_Guidance_Computer

while others appeared out of the blue, as it were...

http://en.wikipedia.org/wiki/IBM_7090
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Harald van =?UTF-8?B?RMSzaw==?=]

This is a very tough room. Let me try again. The question..
"what is meaned by " i = ~0 "..." might translate to..

int i = ~0;

Who says i is declared as int? The original poster didn't, as far as I've
seen. If i is not declared as int, it is important to remember than ~0 is
evaluated as type int (the type of 0), and the result is converted to the
type of i. That is,

unsigned i = ~0;

is not equivalent to

unsigned i = 0;
i = ~i;

even though in this case, for two's complement, the result will be the same.

..What goes on here?

The 0 of course in an integer value with all bits 0. The prefix tilde
performs a binary complement of the value, in this case to all bits 1.

The value of 'all bits 1' depends on how you look at it.

Two's complement suggests -1.
Yes.

One's complement suggests -0.

As was mentioned elsethread, it's called "ones' complement".

-0 is never negative zero. If negative zero is supported, it will compare
equal to plain zero, but you don't get negative zero as a result of any
non-bitwise arithmetic operation, including negation. -0 is equivalent to
+0 .

And ones' complement systems are allowed to say the behaviour is undefined
if ~0 is evaluated. Negative zero need not be supported, and if it is not,
then all bits set is a trap representation.

Signed Magnitude maybe minus INT_MAX?

It's called "sign and magnitude", but right. Which of course equals INT_MIN
for these systems.

 

[Eric Sosman]

Of course but these machines imaginary aren't they?

Of course they are. Completely imaginary. And THAT'S
why the committees who wrote and revised the Standards made
allowance for them. Even when they tightened the allowable
representations in C99, they still allowed ones' complement
and signed magnitude. Simply decreeing two's complement
would have made a lot of things simpler, but the committees
were made up entirely of masochists who loved to make trouble
for themselves. That's why you needn't worry your pretty
little head about it: All the world is a two's complement
32-bit Little-Endian IEEE-floating-point dosbox, and don't
let anyone tell you any different.

Or to put it another way: A friend of mine likes to say
that computing is a fashion-driven industry. Fashions come,
and fashions go, and fashions come again. You can write your
program for this season's hem lines and color schemes, or you
can attempt something a little less transitory. There are,
after all, some distinct infelicities in two's complement:
the fact that abs(n) cannot be implemented reliably stands
out as an ugliness that neither of the alternatives suffer
from, and tomorrow's system couturier may reject that ugliness.
Trap representations for integers are Out today, but in the
face of viral onslaught might not tomorrow's machine revive
the old practice of explicitly-typed data?

Sometimes it doesn't make sense to sacrifice all other goals
on the altar of portability: Portability is just one among many
desirable attributes of a program. But there are *very* few
reasons to engage in gratuitous importabilities like those(?)
in the above code example. You may not particularly like the
ruffles-with-polka-dots theme that all the designers will put
on the runways next year, but it costs you little or nothing
to accommodate it -- and if you don't, none of the hot models
will wear your code.

 

[Richard Bos]

Or to put it another way: A friend of mine likes to say
that computing is a fashion-driven industry. Fashions come,
and fashions go, and fashions come again. You can write your
program for this season's hem lines and color schemes, or you
can attempt something a little less transitory. There are,
after all, some distinct infelicities in two's complement:
the fact that abs(n) cannot be implemented reliably stands
out as an ugliness that neither of the alternatives suffer
from, and tomorrow's system couturier may reject that ugliness.
Trap representations for integers are Out today, but in the
face of viral onslaught might not tomorrow's machine revive
the old practice of explicitly-typed data?

Mind you, for the fashion industry it seems to be lucrative to work only
to today's fashion, and let the airheaded customers buy each year's
fashion in turn. It doesn't seem to do Microsoft any harm, either.

Whether that is a business model you wish to strive for is on each
programmer's own conscience. But lucrative it is.

Richard