>I encounterred a person who said that C++ is an unsafe language.
It is and it isn't. C++ doesn't do much to protect you from doing something wrong, so in that light it's an unsafe language. However, if you do things right, it's perfectly safe. I'd say that person was wrong for making such an absolute and general statement, but a lot of absolute and general statements have some ring of truth.
>but when I input an non-int type,the program will fall in a bad loop.
That's because the code isn't written to handle unexpected input. In this case, cin expects a valid integer. If you don't give it a valid integer, it goes into an error state and won't let you read any more input until the errors are corrected and the error state is cleared. This isn't a case of C++ being unsafe, it's a case of the author not knowing how to properly handle I/O in C++. Try this:
#include <iostream>
#include <string>
#include <ios> // for streamsize
#include <limits> // for numeric_limits
using namespace std;
class bot
{
private:
int password;
public:
bot():password(567){}
virtual ~bot(){};
bool checkpwd(const int pwd)
{return (password == pwd);}
};
int s;
bot b;
int main()
{
for(;;)
{
cout<<"Enter password: ";
if ( cin>>s ) {
if(b.checkpwd(s))
{
cout<<"Access permitted"<<endl<<endl;
break;
}
else
cout<<"Access denied"<<endl<<endl;
}
else if ( !cin.eof() ) {
// Notify the user
cerr<<"Invalid password\n";
// Clear the error state
cin.clear();
// Remove the bad input
cin.ignore ( numeric_limits<streamsize>::max(), '\n' );
}
else {
// The user entered EOF; assume he wants to exit
break;
}
}
return 0;
}
Narue
Bad Cop
15,460 posts since Sep 2004
Reputation Points: 6,464
Solved Threads: 1,401
If your password actually needs to be an integer, which I doubt it needs to be, you be would better taking the input as a string and then converting it to an integer, after parsing out the crap.
iamthwee
Posting Expert
5,950 posts since Aug 2005
Reputation Points: 1,543
Solved Threads: 439
> Do you have any good idears to prevent it?help me please!
Yes, you use fgets() in C, and getline() in C++
Both of which allow you to specify the maximum length of input.
> C and C++ can not prevent the memory from overflowing
Only if you use the poorer archaic API calls which are inhertited from history.
Once again, read EVERYTHING as a string using one of the API calls which specifies a length. Once you have the string in memory, with a known length, then you can make the right choices as to what to do with it.
Salem
Posting Sage
11,531 posts since Dec 2005
Reputation Points: 5,862
Solved Threads: 953
>Do you have any good idears to prevent it?
Yes, if you have code that looks like cin>> s where s is an array, it's wrong. As you've seen, that doesn't protect against a buffer overflow. You can fix it by setting a maximum field width if you really have to use the >> operator:
#include <iostream>
#include <iomanip>
int main()
{
char buffer[5];
std::cin>> std::setw ( 5 ) >> buffer;
std::cout<< buffer;
}
But for reading strings, the getline method is often a much better choice:
#include <iostream>
int main()
{
char buffer[5];
std::cin.getline ( buffer, sizeof buffer );
std::cout<< buffer;
}
>Can anyone tell me what this particular line does...
It's an initialization list for the class constructor. You can get the same effect (in this case) with this code:
bot()
{
password = 567;
}
Narue
Bad Cop
15,460 posts since Sep 2004
Reputation Points: 6,464
Solved Threads: 1,401
>I encounterred a person who said that C++ is an unsafe language.
It is and it isn't. C++ doesn't do much to protect you from doing something wrong, so in that light it's an unsafe language. However, if you do things right, it's perfectly safe. I'd say that person was wrong for making such an absolute and general statement, but a lot of absolute and general statements have some ring of truth.
The definition of 'safe' and 'unsafe' are usually clearly and precisely defined, or definable, and under all versions I know, C++ is unsafe. It's not type-safe, and it's not safe from memory leaks, and exception-wise, it is unsafe, too (and will always be, if you have exit). To state that doing things right makes it perfectly safe is to annihilate any definition of safety, except the one that has to do with whether the language is practical or not.
Rashakil Fol
Super Senior Demiposter
2,658 posts since Jun 2005
Reputation Points: 1,135
Solved Threads: 177
>The definition of 'safe' and 'unsafe' are usually clearly and precisely defined, or definable
Then please provide your reference to a reputable source that makes this definition.
>To state that doing things right makes it perfectly safe is to annihilate any definition of safety
Rather, it makes it a moot point. If you do things wrong, every language will be unsafe in some form or another. If a "safe" language throws an exception, you don't catch it, and the program crashes with an unhandled exception error, how is that safe? It's still a critical meltdown, and the reason it happened in a supposedly safe environment is because the programmer didn't do things right.
If you want to compare safety, you have to define the extent to which safety applies. If you want to break the rules or do something with obviously broken effects to prove that C++ is unsafe, I'll do the same thing with your favorite "safe" language to prove the logical inconsistency.
Narue
Bad Cop
15,460 posts since Sep 2004
Reputation Points: 6,464
Solved Threads: 1,401
