Well it also wouldn't work in a character set that didn't have contigious values for the alphabet. Loctan's function that has the switch in it would probably be the most portable if the string only has lower case charactes.
Printable View
Well it also wouldn't work in a character set that didn't have contigious values for the alphabet. Loctan's function that has the switch in it would probably be the most portable if the string only has lower case charactes.
Even then, it wouldn't take much to make it portable for both.Quote:
Loctan's function that has the switch in it would probably be the most portable if the string only has lower case charactes.
nope, it wouldn't. Though I would change the default to return the value instead of a space
>>I didn't know that you could treat the characters as integers
Yes, instances of type char are just integers to your computer. The entire list of which integer represents which char is called a character set, examples of which are ASCII and Unicode, both of which are in common use in C++.
Because char are integers you can encode messages by shifting any amount, by 1 or 2 or 7 or whatever, pretty readily, but the encoding process is not terribly difficult to break. Also, you need to determine how you handle end of alphabet situations. That is if the result after the shift is larger than 'z' or 'Z' or less than 'a' or 'A' do yo just display the char from the char set representing that integer value or do you wrap around to the beginning/end.
You can also encode in such a way that there isn't a single shift but some irregular, but still definable pattern. Or you can put two sets of char into containers, randomly draw them out one at a time, and correlate one with the other. Or you can use some other "insanely" complicated process to encode your data. The general process is called mapping because there doesn't have to be a clear relationship (simple shifting, etc) between the input and the encoded message, as long as you can figure out/rely on the mapping process.
I agree with the irregular shift, if you only change 1 its barely encryption anymore. A scheme I made once took advantage of number seriess like fibannici numbers and the primes. You could shift by the product of each term along both secuences. The scheme I made was more complex then that though. Also, in loctan's code you need breaks at the end of each case.
Actually no it doesn't. Doing so would result in unreachable code.Quote:
Also, in loctan's code you need breaks at the end of each case.
What do you mean?
I consulted the MSDN and it said that if you dont include the breaks it will run all options from the case to the end of the switch
You are correct, that without a break the control will fall through the cases. But he has returns. returns end the functions. If you had breaks after the returns then there would be no way to reach them.
doh!
I knew that... =/
another thought... does it really matter if you overstep the alphabet in the encryption? the encrypted "string" is merely an array of integers and reversing the "algorithm" would give you correct values within the alphabet range. Surely it doesnt matter that the encrypted string contains characters beyond the alphabet? And what if you wanted to have special characters in you string like 'è'?
Just a thought
u can do some algo of this sort...
1.take in the what the user wants to encrypt
2.generate an array which contains the new character set ,the ones used for encryption
3.find the length of the string the user has entered
4.replace every character in the string with one in your character set.
5.print it on the screen or store it in a file.
to implement it in c++ is up to u now..
and guys plz dont post entire codes.programming be understood by doing it ourselves.you are not helping the guy a bit by postin entire codes.takes the fun out of programming.
DominicTrix, to answer your question it can matter as far as portability goes. Not all character setups will have the same stuff around the values that represent the characters. So lets say 'z' is 35 on a system and the next character is '|'. But on some other system 'z' is 65 which isn't a problem but the next character is '&' and '|' is before 'a'. Now we have a problem.
Note: Character values made up on the fly. They do not intentionally represent any known character set.
Hmmm, but surely any text written on one system and then opened in the other (with different char set will be displayed incorrectly?
well,you will have to pass the original cypher wont you??and i dont think that treating the individual letters as char type,and then after passing the cypher as well,there is going to be any portability problem.Quote:
Originally Posted by DominicTrix