Some basic C++ concepts

My professor told me that the concepts is extremely important than programming.So today he shows us:

char c=0;
c=~c;(which is the bitwise)

so what is c=?

Since C is 00000000,and use not(~) so it is 11111111 now,but he said the answer is -1 instead of 255.Because he says it use one's complement or something~~~so,why it is -1?
(I know it can't be 255,since char is 1 byte with sign,which means it is -128~127,so 255 is out of range,so why it is -1?)

Ok,guys I know I am so stupid since for storing int ,we use two's complement notation,so 1111 1111 means -1.
but I want to know We also ues Excess notation for int,so why this case we use two's complement notation instead of Excess notation?which situations we use Excess notation? thx!

and also for this :

we know 0111 1111 is 127,how about 0111 1111+1 if the variable is char(which is -128~127)?
so because it is 1000 0000 after +1,so 1 is use for sign(-),why the answer is -128?


also for this one,we use two's complement so 1000 0000 means the least num!

So I know I am so stupid,since When we study this in CS 2,our teacher just go through it so quickly and we didn't focus on it since he thinks programming is more important.I know it is an excuse and I should be good at it.

matching values to bit patterns isn't really basic C++, it's implementation-specific C++, and this is specicfic to twos complement bit encodings.

twos complement works a little differently than regular binary math. negative numers are ordered backwards.

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

> but he said the answer is -1 instead of 255
It's the same bit pattern, do you regard 'char' as being signed or unsigned ?

Oh dear. Your teacher makes a LOT of unwarranted assumptions here. Namely:
1) "C is 00000000"
No. There's no guarantee that char has 8 bits, even though that's the most common number.
2) "the answer is -1 instead of 255"
No. Whether char is signed or unsigned is implementation-defined. That's why char, signed char and unsigned char are distinct types. (Unlike the other integral types, where signed xxx and xxx are the same.) Thus, it is implementation-defined whether the result is 255 (unsigned) or ... something else (signed).
3) "the answer is -1"
No. It is implementation-defined (or even unspecified) what negative representation is used, with the only restriction being that an all-zero bit pattern must represent 0. Thus, 2's complement, 1's complement and sign-value are all valid (and have been used at least once), whereas excess representation is invalid (0 is not all-zero).
4) "so it is 11111111 now"
No. That is, not if char is signed and another common condition holds: then it's undefined behaviour. The reason is that ~ does integral promotion, so the result of ~c is actually an int, and all ones at that. The other common condition mentioned above is that sizeof(int) > sizeof(char). If that's the case, then the assignment back to c constitutes a signed overflow, which is UB.

So ... to answer the original question, "what is c?"
If char is signed, the question cannot be answered, since c = ~c is undefined behaviour.
If char is unsigned, c is CHAR_MAX.

Originally Posted by CornedBee

The other common condition mentioned above is that sizeof(int) > sizeof(char).

I think the C standard mandates that his is true.

QuantumPete

Originally Posted by QuantumPete

I think the C standard mandates that his is true.

QuantumPete

It thought the mandated point was sizeof(int) >= sizeof(char).

As to the point of Cornedbee, the behaviour of c = ~c may well technically be undefined for a signed char, but I have yet to see a system where it's not resulting in a -1, and I have worked on several processor architectures: x86, 68K, 29K, ARM, 6502, Z80, 8031, VAX, PDP-11. All of which show this behaviour. So whilst it's technically correct that the result is undefined, it is also quit unusual that the result is something OTHER than -1.

--
Mats

> If char is unsigned, c is CHAR_MAX.

I think this also relies on the fact that an unsigned char is guaranteed not to have any padding bits (isn't it UB to modify padding bits?). I'm not sure what, if any, guarantees regarding padding bits exist for signed char (specifically, in C90, C99, and C++).

Originally Posted by QuantumPete

I think the C standard mandates that his is true.

QuantumPete

No, it doesn't - it's guaranteed that 1 == sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long), but it's possible that they could all be equal to 1 (though this would require a char to have at least 32 bits, which is allowed, since the standard doesn't imply any upper limit on CHAR_BIT, only a lower limit of 8).

Originally Posted by robatino

No, it doesn't - it's guaranteed that 1 == sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long),

my mistake

tx1988,

Binary is very difficult for beginners, simply because cin and cout don't support binary, and you can't see what you are doing!

It requires a bit more code to display binary. If I were teaching the course, I would assign you to write a program that displays in binary, before getting into bit manipulation. You might want to try that in your "spare time".

This can be done "the hard way", by writing your own functions). Or, this is fairly easy to do with <bitset>. And, you can input numbers in almost any base (formatted as a string) with strtol().

In the "real world", people are rarely interested in the integer or decimal value when manipulating bits. It sounds a bit strange, but although it is clearly a number we don't care about it's value. I suppose it's like ASCII characters... They are numbers, but they represent characters.

When we want to "see" the "bit pattern", we will usually display it as (unsigned) hexadecimal number. It is much easier to convert between hex and binary, than between decimal and binary. With a little practice, you can learn to convert numbers of any size in your head. (You only have to memorize 16 conversions... You already know 0 and 1.

My professor told me that the concepts is extremely important than programming.

Yes, it is important to know, and every college-level computer science major has to be very comfortable with binary (and hex). However, it's not something that most programmers use every day. It's of more use to hardware guys (like me) and to progrmmers who program "close to the hardware"... programmers who write drivers & firmware, or who program in assembly language.

in CS 2,our teacher just go through it so quickly

Yes, I would expect college-level programming to be very fast paced, and to require more homework-time than your average class. But, I would have expected CS1 to be even worse, since most of the concepts are new to most students. The "introductory" classes are usually the hardest, in any subject!

CS1 was a lot of hand holding in my experience, CS2 was when they started teaching real programming, and that is when most students find out they are not cut out for it, after that, it is the second year classes that separate the programmers and the people who are just kinda interested in computers.

SO,now You guys mean that I should continue working hared on the concepts or just simply know something about it.Because My professor told me to be a computer science major,we should be good at programming,concepts,hardware,circuits,and of course calculus.In fact,I am interested in how to programming and how to use software more than knowing how it works,because I maybe want to be a statistic major who also good at computer software(like using SPSS,SAS or VB , VC )
support my work in data analyse and statistic like working as a Actuary(which is one of the most
hardest major in the world requiring a lot of hard exams and many years for studying) .


Can some of you guys who is former programmer tell me what courses needed for CS major and
is it easy or hard to be good at CS major~~~?
THX for your experience!