Hi.
I would like to ask how do I differentiate an integer is Signed or Unsigned?
From what I have read so far, Signed integers have '1' at the most left of a binary number. However, an Unsigned integer also has the possiblilty of having a '1' at the most left isn't it? Then, how do I recognise them?
There is a way you can find out actually.. XOR the bits of your value with something like 0xFFFFFFFF and see if it flips from positive to negative, or negative to positive.
1 2 3 4
int a = 200;
unsignedint b = 200;
a = (a ^ 0xFFFFFFFF); // a == -201
b = (b ^ 0xFFFFFFFF); // b == 4294967095
I dunno, it's something anyway. :B
Edit: Also, @noobgrammer: It's not that signed integers have a 1 at the left most bit, it's that the left most bit is used to designate the sign, 0 meaning positive 1 meaning negative.
Well, an unsigned int will be able to hold a positive number twice as large as a signed int, since it can use the left most bit for a value instead of a sign. Obviously this means you can't get a negative number however.
As an example for usage, if you have a number you want to make sure can never be a negative, an unsigned int could be a way to go.
No problem. The maximum range of a signed int and an unsigned int basically stays the same, they're just shifted on the number line.
For example, the range between 0 and 20 is the same as the range between -10 and 10, one just has half its range placed below zero, and the other doesn't. Similar idea with signed and unsigned, though in this case it's an odd number, with the extra digit placed on the negative side. But you don't really have to worry about that.
I know that this thread has been marked as solved but it's worth mentioning that the range of an unsigned int and a signed int can be seen within the <limits> header module.
Ikaron's solution bothers me because it relies on "outside information" as firedraco said. In reality the bit representations are all exactly the same and you can never tell them apart simply because, they're identical. You just have to decide which way you want to look at those bits, from either a signed perspective or and unsigned perspective.
Ikaron's solution is not a solution because if you have your bits in a signed int or an unsigned int then you already know its signedness, no?
That's why unsigned integers have a greater range of magnitude (by a power of two, of course) than signed integers -- because they have that extra bit of significance.
Again with the assuming of things, Duaos. We seem to of had this problem before, no? I'd send a PM again and keep from throwing this out on the forums but considering you ignored it last time...
I never claimed it was a solution, just that you can determine a signed int from an unsigned int by flipping the bits and viewing the result. "Outside information" is completely ambiguous, so depending on how one decides to interpret it my idea could very well be a solution, but even then I don't claim it to be one because there'd be no serious reason to do it in the first place.
I simply said there's a way to tell without knowing "unsigned int x", and if for some reason you have a function that you want to determine if a value being passed to it is signed or unsigned, that's a way you can do it. I know that the bits are exactly the same, that's why I even suggested that reversing them all would work to begin with.
So if I never claimed my "solution" was a solution, then it 'never being a solution' isn't a problem is it? So pointing this out is absolutely redundant.
xD If The Father loves us, why does stuff like system() exist to be taught as a proper method of programming in C/C++ at schools across the world? There's a hidden motive somewhere, I just know it.
I simply said there's a way to tell without knowing "unsigned int x", and if for some reason you have a function that you want to determine if a value being passed to it is signed or unsigned
Except you DID just do "unsigned int x" and you can't make a function that deals with a signed or unsigned int without putting it into a signed or unsigned data type, thus changing it from whatever it was originally.
So if I never claimed my "solution" was a solution, then it 'never being a solution' isn't a problem is it? So pointing this out is absolutely redundant.
Honestly, that's kind of a dumb response. When you post a reply to OP's post, it was assumed (even by the OP) as a solution. If you don't want it to be, you have to say. And don't say "but there, you are assuming again!" because without assumptions no-one would ever get anywhere. Your post is pretty much just a description of what a signed and an unsigned int is, which isn't really even relevant. >_>
The OP just asked if there's a way to tell. Which there is, which is what I posted. The first question wasn't very difinitive in what it was asking. I'll say again, I only posted a way to distinguish one from the other from within the program. If you can locate in memory and invert the bits of an integer of some other program, or function of a program, depending on the situation and how the program may respond, you could tell if that integer went from positive to negative, or to a drastically different positive number.
I will agree that my post could have been made clearer than it was, but I could also say that the OP could be made clearer than it was, as could your post, firedraco. You could have elaborated on what you meant by 'Outside information' for example. Seems to just be a common problem regardless.
As for the first part of your post, firedraco, you're right. It was a bad example. The entire point I was trying to make was that you can make the program aware and behave accordingly if something is signed or unsigned. That you can give it a signed int and it can tell you it's signed, or you can give it an unsigned int and it can tell you it's unsigned. I thought I pointed out that there wouldn't be much use for it in my initial response, which is why I have the 'I dunno, it's something anyway :B' at the end, but it would appear that I edited it out by accident. So I apologize for the misunderstanding.
I also apologize for getting annoyed, my last experience with Duaos wasn't great and I perhaps reacted too quickly to his post in this thread.
OP: "Hey all, can I tell if a bunch of bits represents a signed or unsigned number?"
FD: "No. You have to know a priori."
Ikaron: "There is a way you can find out actually.."
OP & Ikaron have some useful posts...
LB & me: "@Ikaron, er, there really isn't a way..."
Ikaron: "FLAME ON!"
Ikaron: "PS. I hate you because you didn't take my flame-bait when I PMed it to you that one time..."
MR: Relevant, nonsensical fun. (Thanks!)
Ikaron: "Desire to flame, subsiding..." Eats another donut.
FD: Speaks truth.
Me: Flame-bait.
If you can locate in memory and invert the bits of an integer of some other program, or function of a program, depending on the situation and how the program may respond, you could tell if that integer went from positive to negative, or to a drastically different positive number.
That's not how it works though. You have some memory, say "10101010". What type is that? You can't know, ever. There is no way to know unless you have already known before. By assigning it to an int or an unsigned int you are just forcing a specific type to be displayed, regardless of what it was originally.
Duaos, you immediately called me out for having failed programming methodology before I had ever even posted a single line of code and I tried to convey how I felt about it to you via PM so I didn't throw the thread off topic. I had initially come here doing my best to word out my posts as clearly as possible, spell and grammar check them to the best of my ability, but does this just not matter in light of 'rawr you said something incorrect and thus are now a terrible community member.' ?
Also, I have not once personally insulted you Duaos, so why do you proceed to do so to me?
@firedraco: Well what I meant was that you could interpret a program's response to having its data changed. Say if you had a fucntion that moved an object but didn't do much checking. Lets say it uses a signed int for forward and back, positive with forward, negative with back. If an object is moving backwards and you find the integer in memory representing that object's movment and invert the bits, it will change directions. You can interpret this as a signed int, just because behavior wouldn't really reflect the same way if the function were designed to use unsigned ints.
It's sounding sillier as I talk more into it, but it made sense to me at the time. xD I'll try to make my intents of a post more clear next time.
The thing is, in these C++ programs you have to tell it how to handle it by specifying its datatype. By specifying it, you aren't learning anything about what it was 'intended' to be or 'created' as. Just like firedraco says, the data is just bits in memory. You choose how to handle it, and unless you have outside sources telling you, the bits themselves tell you nothing about the data, just the data itself.
Well yeah, if we're talking about strictly the data and memory then my statement is entirely incorrect. I was viewing it as finding out if an int in memory is signed or unsigned -through- the program that is using it, so I guess there's just a bit of a misunderstanding of what first caught my mind.
Just as a random experiment (because it wouldn't have practical use as far as I can tell), if you had Program A pipe the address of an int to Program B, Program B could determine whether the value being held by Program A is signed or unsigned by requesting the value of the int, inverting the bits, and requesting the value again. (Unless of course the value sent is already negative) Program B would never have the absolute knowledge of 'signed' or 'unsigned', just the change Program A experiences from the action ProgramB takes. This is just a loose example of what I'm thinking, in hopes that why I saw it the way I did could be better understood.
I didn't mean to suggest that you could determine sign, or even type, just by looking at the memory.