what is the differenece between "signed" and "unsigned"

[henrywong]

what is the differenece between "signed" and "unsigned"

[L0M4jE8b]

Hello henrywong,

signed allows for negative values and unsigned does not. Therefore unsigned can have more (positive) values then unsigned.

[henrywong]

yup..
Now i know the meaning of them..
thx

But...

#include <iostream>
using namespace std;
#include <iomanip>
#include <cstdlib>
int main()
{
	unsigned seed;

	do{cout<< "Enter seed: ";
	cin>> seed;
	}while(seed<0);

	srand( seed );
	for(int x=1;x<=10;x++){
		cout<<setw(10)<<( 1+rand()% 6);
		if(x%5==0){
			cout<<endl;
		}
	}
	return 0;
}

if unsigned cannot contain any -ve interger
But
1)why I still can input the -ve number?
2)How can I block the -ve input?

[vince1027]

This is a good question and a good observation you had.

If you know Two's complement, you'll understand this better. For a brief discussion, let's take an example.

A 3 bit two's complement

bit     unsigned    signed
000     0            0
001     1            1
010     2            2
011     3            3
100     4           -4
101     5           -3
110     6           -2
111     7           -1

You see, for some cases it does not matter if an unsigned takes in a negative representation of a group of bits. If I set an unsigned to be -1 then it will represent the largest unsigned value possible.

That -1 example is the reason why std::string::npos has a constant -1.
http://www.cplusplus.com/reference/string/string/npos.html

[analoganomaly]

Try this:

#include <iostream>
#include <iomanip>
#include <cstdlib>

using namespace std;

int main(){
	unsigned seed;
tryagain:
	std::cout<< "Enter seed: ";
	std::cin>> seed;
    if(!cin){
            std::cout<<"Bad input.\nPlease specify a numeric value.\n";
            cin.clear();
            cin.ignore(std::numeric_limits<streamsize>::max(), '\n');
            goto tryagain;
            }else if(seed<0){
                       std::cout<<"Unable to use negative integer. Please try again.\n";
                       goto tryagain;
                       }else{}

	srand( seed );
	for(int x=1;x<=10;x++){
		std::cout<<setw(10)<<( 1+rand()% 6);
		if(x%5==0){
			std::cout<<"\n";
		}
	}
	system("PAUSE");
	return 0;
}

I didn't compile but it should work. I'd recommend using \n instead of endl. I also recommend using std:: before your cin and cout to avoid potential nastiness. Though your appropriate use of using namespace std; helps avoid errors.

Granted I'm by no means an expert. Nor have I had classes of any kind.
Goto's are generally frowned upon for the reason of spahghetti linkages. If it really bothers you just export it to a function and call the function. Personally I come from a procedural background and am in the process of expanding my horizons to OO languages like C++.

[vince1027]

It's all personal preference whether to append the namespace at the beginning of a method/object or use the using directive. Many software companies, prefer to use the using directive and not append the std namespace for readability purposes.

I suggest to get used to seeing both but never limit yourself using a specific preference -That's bad practice.

std::endl is more appropriate because if you are using buffered streams, std::endl will flush the buffer for you. Although in many cases you will want to be explicit and clear out the buffered streams yourself, it is always a good practice to be extra careful.

[analoganomaly]

Agreed with namespace. Though I've found using std prior to cin and cout more worry-free. Getting used to both is indeed something one ought to get used to. However I must disagree with endl.

endl calls the flush() method. That means more work done per use, and is less efficient than '\n'. Not to mention endl; is more work to type out than \n.

The theory behind stream flushing is that you prompt the user to do something and then ask for input. But on some systems the prompt isn't shown until the stream is flushed, ie. all unwritten characters are written to the output device, and then the user doesn't know what to do.

This however, doesn't apply in C++ because cin and cout are tied together and any request for input on cin will automatically flush cout. In fact, most of the time you want to flush a stream, it gets flushed for you automagically and is therefore redundant to use something that explicitly flushes the stream for you,

Some might argue that endl; is more portable than \n. Unix uses \n, win32 is supposed to need \n\r and mac uses \r. However I've never had any problems getting the desired result on both unix and win32 with just \n. Given my personal hatred of Mac's I haven't had much occation to write anything for them.

It should suffice to say, though it's generally a matter of preferance, there's more reasoning behind my own preferance of \n over endl; than my simple lethargy... which I don't deny being guilty of.

Again though, I'm fairly new to C++ and could be entirely wrong. Any corrections are quite welcome. ^_^

[vince1027]

The flushing only occurs when you use the std::endl with a buffered stream. I do not think it flushes if you are not using a buffered stream because like you said, streams are flushed automatically.

So if you use std::endl on a non-buffered stream, it will just append the new-line character.

As for the portability issue, I do not think the std::endl solves that problem. As far as I know, std::endl will just append the new-line character '\n'. That new-line character problem is more prevalent in Java. Hence the recommended line printing is the System.out.println(). Because the byte code can convert the new line character depending on what platform.

By the way, the DOS new-line character requires CR+LF (\r\n), the other way around of what you said.

There's nothing wrong if you prefer '\n' over the std::endl. Like I said, std::endl is more appropriate for buffered streams but is not really a recommendation nor a suggestion for good practice if your goal is to specify a new-line character.

[analoganomaly]

Quote from vince1027 on Mar 13, 2008 at 8:00pm:
By the way, the DOS new-line character requires CR+LF (\r\n), the other way around of what you said.

I stand corrected. Thank you. ^_^