1

I have a homework assignment where I have to make a function that is used to reverse the effects of a caesar shift on a string. For example, if the string after the shift is "fghij", and the shift value is 5, the function should yield "abcde." This works when I try it on visualstudiocode. When I submit the assignment, it seems as if my function did nothing. The function is as follows:

string decryptCaesar(string ciphertext, int rshift)
{
    string plaintext;
    int cipher_length = ciphertext.length();
    for(int a = 0; a < cipher_length; a++)
    {
        char individual = char(ciphertext[a]);
        if(isalpha(individual) == true)
        {
            if(65 <= int(individual) && int(individual) <= 90)
            {
                individual = char(((int(individual) - 65 + 26 - rshift) % 26) + 65);
            }
            else
            {
                individual = char(((int(individual) - 97 + 26 - rshift) % 26) + 97);
            }
        }
        plaintext += individual;
    }
    return plaintext;
}
user1529
  • 13
  • 3

1 Answers1

1

For a start, the values returned from the classification macros (like isalpha) are nonzero if the character falls into the tested class, and zero if not. See this answer for some more detail.

However, the true constant has only one value, so you should not compare the two (true may be the value 1 but isaplha() may return 42).

Instead, simply rely on the fact that non-zero integers become "true" when interpreted in a boolean context:

if (isalpha(individual)) {
    blahBlahBlah();
}
paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • `if (isalpha(individual))` and `if (isalpha(individual) == true)` are equivalent: in both cases `isalpha(individual)` is converted to `bool`. What am I missing? – bolov Oct 24 '22 at 23:41
  • @bolov Actually in the second case `true` is converted to `int` instead of `isalpha(individual)` being converted to `bool` – Nathan Pierson Oct 24 '22 at 23:42
  • Also "`true` may be the value `1`" is understating things. `true` is always promoted to `1` according to the rules of [integer promotions](https://en.cppreference.com/w/cpp/language/implicit_conversion#Integral_promotion) – Nathan Pierson Oct 24 '22 at 23:43
  • Ok so it works now, but my program has a decryptCaesar function and a decryptVigenere function, and the same thing is happening on the decryptVigenere function now. The Caesar issue works though I think, I removed the "== true" part. I did that for the Vigenere function but it's the same thing, works on vscode but not on gradescope. Should I make a new question? – user1529 Oct 24 '22 at 23:43
  • @bolov: @Nathan is correct. The rules are (basically) types are converted to the one with the highest rank. That's `int` in this case. And, yes, a new question would be better. – paxdiablo Oct 24 '22 at 23:44
  • 1
    If you have a separate problem with separate code, that's a new question. – Nathan Pierson Oct 24 '22 at 23:45
  • yep, I just checked, `true` is converted to `int`. I never would have guessed. This is stupid. Either the promotion rules or the implicit conversions or the fact that `is_whatever` doesn't return `bool` or all of them. The fact that `is_whatever() == true` is a bug is a language fail ... imho – bolov Oct 24 '22 at 23:46
  • @bolov: There's a lot of legacy code, especially ported from C language, involving the `is_whatever` functions. So as not to break a lot of programs, the C++ committee decided not to change them to return `bool`. – Thomas Matthews Oct 24 '22 at 23:49
  • @bolov, it's acting *exactly* as the standard specifies. You have to remember that the classification macros come from the earliest C implementations where `bool` did not exist. A prime concern when issuing a new iteration of the standard is to not break *existing* code. This code *is* a bug because it wrongly assumes that the classification macros return true or false and nothing else. – paxdiablo Oct 24 '22 at 23:49
  • I understand reasons why it's like this. There was no sensible way to solve this without breaking compatibility with C and compatibility with C is non-negotiable. I do understand that. My point is that whatever the reasons may be it is an unfortunate effect of the language. At some point the cost of legacy must become too much, but that is another discussion. – bolov Oct 24 '22 at 23:56