4 ms·

Something as simple as malloc requires a cast in C++ when it is not needed in C, so type errors for even simple code.

• MaxBarraclough 6y ago
  What type errors? Do you mean that, to get it to compile as C++, you have to add an explicit cast? That isn't a significant burden. Requiring explicit casts, and forbidding implicit conversions, reduces the odds of being surprised by an unwanted conversion. There's a good argument to be made for adding explicit casts to C code even when the language doesn't require them. GCC's -Wconversion flag can help with this.
  • ByteJockey 6y ago
    But the conversion of the result of a malloc call is neither surprising nor unwanted. There's also no ambiguity. You've already explicitly defined the variable's type at that point.
    • MaxBarraclough 6y ago
      There's very little harm in making the conversion explicit. It's more verbose, but it's also more explicit, which is a good thing. There is harm in implicit conversions catching the programmer unawares. This is a fairly significant cause of bugs in C code, and it's why C++ uses stricter rules, requiring you to always make these conversions explicit, even when using malloc.
      • steveklabnik 6y ago
        There is a significant group of folks that believe it is actively bad. I don't write enough C these days to have a stance, personally, but https://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc https://stackoverflow.com/questions/605845/do-i-cast-the-res...
        • deleted 6y ago
          [deleted]
        • ncmncm 6y ago
          There is a significant group who are wrong about literally anything one can think of. How vocal they are about it does not correlate with much.
          • ByteJockey 6y ago
            But that fact does not get us any further towards figuring out who is wrong. It merely tells us that people disagree.
            • ncmncm 6y ago
              People still coding C can usually be counted on to be wrong.
      • ByteJockey 6y ago
        You're not entirely wrong, but in the context of the specific example given (malloc), it's about as implicit as c++'s auto keyword, it just obscures type information on the right side instead of the left side of the assignment from the programmer. I would also argue that there's a hard to quantify harm in making code more verbose. More visual noise makes it harder to parse what's going on. Sure, one redundant cast isn't going to kill you. But many sources of repetition across an entire code base eventually turn it into a slog where the parts you want are obscured by useless noise.
  • josefx 6y ago
    > What type errors? Do you mean that, to get it to compile as C++, you have to add an explicit cast? Yes. > That isn't a significant burden. But once you do it your "C" code is littered with a lot of unnecessary casts that increase the verbosity of the code and could hide errors. With pre C99 code it would also hide default int errors if the include for malloc gets lost at some point.
    • MaxBarraclough 6y ago
      > and could hide errors How? As I said, the stricter rules of C++ result in fewer type-conversion errors than C's permissive rules. That's the reason for C++'s stricter rules, and it's the reason Ada is even stricter. As an example, consider a = b = c; In a languages with permissive rules about implicit conversions, you have to inspect the variables' types to determine whether this statement is equivalent to b = c; a = c; (Even ignoring OOP, that is.) > With pre C99 code it would also hide default int errors if the include for malloc gets lost at some point. Wouldn't it just fail to compile if you're missing a required header? edit steveklabnik linked to [0] so I see what you mean now. I think that's a valid point. [0] https://stackoverflow.com/a/605858/ https://stackoverflow.com/a/605858/