Re: encryption problem
In article <46abd292$0$9933$39db0f71@news.song.fi>,
nospam@thanks.invalid says...
[ ... ]
Anyways, even though technically not supported by the C++ standard
(as far as I know), in practice 100% of systems (at least those which
you care) use the ASCII codes for the first 127 characters in the
character set (even if the input is UTF-8 encoded).
Add to this that in C++ for example 'A' means the ascii value of
that character, and suddenly you can check if a certain character
is, for example, between A and Z by a simple (c >= 'A' && c <= 'Z').
OTOH, by using std::isupper, you get portability and often even better
efficiency -- not to mention more readable code. Then again, with other
methods of mapping, you don't need to use the step at all.
Another feature in C++ is that characters are simply integer values
and thus support integer arithmetic. This allows an ample set of nice
conversions to be done with simple math. For example, if you want to
map 'A' to 'Z', 'B' to 'Y' and so on, you can do it with a simple
'Z'-(c-'A'). The (c-'A') part maps the character from the range
'A'-'Z' to the range 0-25, and this value is then substracted from
the ascii value 'Z'. The result is that 'A'...'Z' gets mapped to
'Z'...'A'.
Once again, there's another method that is not only portable, but also
likely to be more efficient as a rule -- just build a table to look up
your translated values, and you get get it all, so to speak.
[ ... ]
char plain_text[80]; //plain text string
Have you ever heard of the term "buffer overflow"? That kind of
code you have written above is exactly one of the causes. Don't do it.
A fixed array does _not_ necessarily have much (if anything) to do with
buffer overflows. Using something like fgets, it's entirely possible to
do so with complete safety. Don't get me wrong: I'm not arguing against
using a string and getline, just pointing out that you're overstating
the shortcomings of fixed-size arrays in this situation.
In C++ there's no need to use fixed-sized arrays for text because
there's this useful class called std::string. It will dynamically
grow itself as necessary and thus buffer overflows can be avoided.
The buffer overflow is avoided, but replaced with the potential for a
denial of service attack, which is not necessarily a huge improvement.
Another plus side is that std::string is way easier to use than
char arrays and C string functions. It's usually a lot faster, too.
cout << "text: "; // enter some text
cin >> plain_text; //assign the array of text to plain_text
Here is the critical point. What happens if the user enters more
than 80 characters?
It generally still won't cause a problem. The real problem here is that
this only attempts to read and encrypt the first word entered by the
user. A buffer overflow results only when/if the user enters 80
characters or more without any whitespace.
You don't want to do that. You want to do this:
std::string plainText;
std::cout << "text: ";
std::getline(std::cin, plainText);
Now it doesn't matter how much text the user writes. It won't cause
a buffer overflow.
This is a real improvement, but there's quite a bit more to it than
avoiding a buffer overflow.
[ ... ]
plainText.length() will give the length of the string when you need
it. And way faster than strlen().
It may be faster -- it certainly _can_ be. Then again, in some
implementations it's NOT any faster at all -- in fact, it's minutely
slower. I'll repeat: I'm not arguing against using std::string -- just
pointing out that your argument is a bit overstated.
[ ... ]
std::string plainText;
std::cout << "text: ";
std::getline(std::cin, plainText);
for(unsigned i = 0; i < plainText.length(); ++i)
{
char c = plainText[i];
if(c >= 'A' && c <= 'Z')
plainText[i] = 'Z' - (c-'A');
}
std::cout << plainText << "\n";
There are quite a few other ways of doing the "encryption" while
maintaining efficiency and portability. Here's a way of doing it that's
a bit more extensible, such as making it easy to add support for
characters with accents, umlauts, etc., in a language of your choice,
instead of being restricted to English.
#include <iostream>
#include <iterator>
#include <algorithm>
#include <iomanip>
#include <limits.h>
// Just for grins, we'll put the encryption into a functor:
class encrypt {
char table[UCHAR_MAX];
static const char *un;
static const char *en;
public:
// here we build our encryption table:
encrypt() {
for (int i=0; i<UCHAR_MAX; i++)
table[i] = i;
for (i=0; i<strlen(un); i++) {
table[un[i]] = en[i];
// might as well support lower-case...
table[tolower((unsigned char)un[i])] =
tolower((unsigned char)en[i]);
}
}
// do the actual encryption using a simple table lookup.
char operator()(char ch) {
return table[(unsigned char)ch];
}
};
// Here are the real tables that handle the mapping.
// If you wanted to handle a language other than English,
// you'd add the appropriate plain/encrypted characters here.
// Each character in the un string maps to the corresponding
// character in the en string.
const char *encrypt::un = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
const char *encrypt::en = "ZYXWVUTSRQPONMLKJIHGFEDCBA";
int main() {
std::cin.unsetf(std::ios_base::skipws);
// encrypt (or decrypt) from cin to cout:
std::transform(std::istream_iterator<char>(std::cin),
std::istream_iterator<char>(),
std::ostream_iterator<char>(std::cout),
encrypt());
return 0;
}
--
Later,
Jerry.
The universe is a figment of its own imagination.