4 ms·
> C language has some very limited implicit type conversions What? C will happily compile this: void g() { float f = 3.14; int* ip = &f;
by fbkr 6y ago
> C language has some very limited implicit type conversions
What? C will happily compile this:
void g() {
float f = 3.14;
int* ip = &f;
}
C++ has no such _craziness_. Your strawman actually has pretty good uses:
complex c = 3i;
... = c + 4;
Would you rather have the last line not compile because 4 is not a complex number? Because one _could_ argue that 4 is a complex number, and C++ can represent this with an implicit constructor.
The issue with C++ is that implicit is the default, not that it exists.
- moonchild 6y agoThe second case is easily solved by having an overload operator+(complex lhs, int rhs). No need to convert anything.
- brianush1 6y agocomplex c = 4; Would you rather have this line not compile because 4 is not a complex number? Because one _could_ argue that 4 is a complex number, and C++ can represent this with an implicit constructor. The issue with C++ is that implicit is the default, not that it exists.
- eru 6y agoHaskell solves this reasonably well. If your data type implements the Num typeclass, you can use literals like 4. (A typeclass in Haskell is similar to what they call an interface in Java.) There's no automatic conversion happening at all. It's done via overloading literals at compile time. (You can do the same for strings.)
- srg0 6y agoC++20 introduced concepts, and now it's possible to specify type constraints, like integral, in a way similar to Haskell typeclasses. What it doesn't solve that by default the compiler tries to find an appropriate implicit conversion. Sometimes it's convenient, sometimes it's harder to see what the code actually does.
- eru 6y agoYes, concepts help a bit, but I'm not sure whether they would be necessary here. Yes, the implicit conversion for all values is part of the problem. The Haskell approach only gives you magic for literals.
- fbkr 6y agoThis fails when you want `4 + c` or `c + 4.f` etc. So you either have a gross number of overloads doing the same thing, or you just put an implicit constructor to `complex`. Also, I agree that implicit conversions in general should be avoided, but this complex number example feels like the perfect use case.
- 59nadir 6y agoOne of the main gripes I have with C++ is exactly what you said, that the defaults usually are the wrong for the usual cases and for general sanity. With that said, C programmers also seem to love their implicit behavior so it's pretty clear where this kind of thinking comes from.
- cygx 6y agoC will happily compile this Only if you ignore your compiler output: Even TinyCC will warn about that one on default settings. With the flags I use, the code would in fact fail to compile.