6 ms·

Why do we need to be able to add two characters again?

• qmmmur 7y ago
  String forming.
  • vardump 7y ago
    How would you form strings by adding 'char' type values together? This is not about concatenation operation, we're talking about C/C++. They do not have syntactic sugar concat for chars. (In C++, you of course have operator overloading, that's how std::string concat sugar works.) '1' + '1' == 'b'. Because 49 + 49 == 98. ASCII '1' == 49, and 'b' == 98.
• vardump 7y ago
  That's a good question, now that we have [u]int8_t, [u]int16_t, etc. for explicit bitness values. (Although both can have more than specified number of bits on some platforms.)
  • ynik 7y ago
    But `uint16_t + uint16_t` has exactly the same problem -- if it's a typedef for `unsigned short`, there will be promotion to either `int` or `unsigned int`. A multiplication `uint16_t * uint16_t` can still cause an overflow after promotion to signed int, which is undefined behavior! So "unsigned types wrap around" doesn't apply to `uintN_t`, because you can never know for sure whether those types are "smaller than int" and thus get promoted to signed types when you do any arithmetic. Of course, in practice this just means: every C and C++ program relies on tons of implementation-defined behavior. A `sizeof(int)` greater than 32-bits would break most code in existence (e.g. hash code computations using `uint32_t`).
    • vardump 7y ago
      > A multiplication `uint16_t * uint16_t` can still cause an overflow after promotion to signed int Last time similar thing bit me was when the platform had 16-bit int... so just adding two int16_t can very well cause int overflow.
    • wahern 7y ago
      > because you can never know for sure whether those types are "smaller than int" and thus get promoted to signed types when you do any arithmetic You can deduce the width (number of sign + value bits) of the standard integer types from their limits (e.g. INT_MAX, INT_MIN, etc). The problem has been that this is non-trivial if not impossible to do from the preprocessor. The next C standard will include width constants (e.g. INT_WIDTH) for the standard integer types.
    • loeg 7y ago
      In practice programs on these weird large-int machines would just use `-fwrapv` and move on.
  • nwellnhof 7y ago
    No, uint8_t is guaranteed to be exactly 8 bits wide (unlike uint_fast8_t or uint_least8_t).
• XMPPwocky 7y ago
  char toupper(char c) { if (c >= 'a' && c <= 'z') { return (c - 'a') + 'A'; else { return c; } }
  • thaumasiotes 7y ago
    It's worth mentioning explicitly that while `c - 'a'` is the more obvious application of character addition in your example, `c >= 'a'` is another one that's even more common. Pretty much everyone immediately understands that we want to be able to sort characters.
    • XMPPwocky 7y ago
      Yeah- but the problem of poorly-defined result type isn't present for comparison operators, since a bool is a b... oh, hold on, C. Since an int is an int. Sigh.
      • slavik81 7y ago
        In C, 'a' is an int so most of those are not char/char operations. In C++, 'a' is a char and the comparison result is a bool, though it doesn't really make a difference in that function.
      • thaumasiotes 7y ago
        When you're sorting, you're generally comparing two variables to each other, as opposed to comparing one variable to a literal constant.
  • brudgers 7y ago
    The Erlang is Perlilous: toUpper(char) -> $ + char. % It's "$ "
  • kccqzy 7y ago
    You showed an example of subtracting a character from another. The GP asked for an example of adding two characters.