3 ms·
> 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
by 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 agoI 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.