3 ms·

> C++ compilers will reject a lot of good C code, mostly because it disallows implicit casts from void * When did code that implicitly casts from void * become

by sjolsen 12y ago

> C++ compilers will reject a lot of good C code, mostly because it disallows implicit casts from void * When did code that implicitly casts from void * become "good?" Implicit conversions from A to B should never happen unless it's statically known that A can be represented as B, and that's generally not the case when A is type-erased, as when it's referred to through void *.

mikeash 12y ago
The typical case is when you call malloc. There's a ton of C code that looks like: sometype *ptr = malloc(...); A C++ compiler will reject that.
- sjolsen 12y ago
  > The typical case is when you call malloc. And if there were a proper type-parameterized entry point to malloc (be it a function or macro) for general-purpose contiguous-object allocation, you wouldn't have to compromise the already weak type system with what is possibly the single most absurd implicit conversion possible from a type system perspective just to avoid typing out the type name three times. I suppose it's more of a language quality issue than a program quality issue, but reducing verbosity by undermining the type system rather than providing a simple "allocate<T>(n)" function, especially in a language that doesn't care about verbosity enough to provide even the thinnest of syntactic abstractions, is just ridiculous.
  - mikeash 12y ago
    I agree completely, but none of that changes the nature of C nor the code written in it. If you want to change the API like this, more power to you, but don't then say that existing code still compiles fine.
    - sjolsen 12y ago
      > but don't then say that existing code still compiles fine. Oh, I'm not disputing that a lot of existing C code wom't compile as C++; I'm just nitpicking the claim that good C code won't compile as C++. ;) But to be fair, there are perfectly good, valid C programs that don't compile as C++, void * aside.

by sjolsen 12y ago

mikeash 12y ago

The typical case is when you call malloc. There's a ton of C code that looks like: sometype *ptr = malloc(...); A C++ compiler will reject that.

sjolsen 12y ago
> The typical case is when you call malloc. And if there were a proper type-parameterized entry point to malloc (be it a function or macro) for general-purpose contiguous-object allocation, you wouldn't have to compromise the already weak type system with what is possibly the single most absurd implicit conversion possible from a type system perspective just to avoid typing out the type name three times. I suppose it's more of a language quality issue than a program quality issue, but reducing verbosity by undermining the type system rather than providing a simple "allocate<T>(n)" function, especially in a language that doesn't care about verbosity enough to provide even the thinnest of syntactic abstractions, is just ridiculous.
- mikeash 12y ago
  I agree completely, but none of that changes the nature of C nor the code written in it. If you want to change the API like this, more power to you, but don't then say that existing code still compiles fine.
  - sjolsen 12y ago
    > but don't then say that existing code still compiles fine. Oh, I'm not disputing that a lot of existing C code wom't compile as C++; I'm just nitpicking the claim that good C code won't compile as C++. ;) But to be fair, there are perfectly good, valid C programs that don't compile as C++, void * aside.