6 ms·
> Implicit type conversions are inherited from C, the language you called "awesome". It is true that C language has some very limited implicit type conversions
by flowerlad 6y ago
> Implicit type conversions are inherited from C, the language you called "awesome".
It is true that C language has some very limited implicit type conversions. For example you can say:
long n = 3;
And the integer 3 is converted to long. This is extremely limited, and does not make the program hard to understand, which is completely different from the craziness you see in C++.
- beyondCritics 6y agoC does destructive conversions automatically, if you ask for it. E.g. unsigned n; n = 2.99; // n = 2 n = -1; // n = 2^M-1; n = 1.0E33; // undefined but not catched Both C and C++ follow the same philosopy: "Trust the programmer". The programmer is expected to use his expressive freedom, to solve performance problems and stay away from problematic constructs without being told to so. C is a systems programming language from the 70's, designed to solve performance problems and C++ inherits from that. It is true, that in C++, you can overload assignment, addition and throw exceptions everywhere, thus making even simple expressions like auto n = a + b; completely unpredictable. But the coder simply has abused the freedom C++ gave him. T some extent, the same is possible in C, look here https://www.ioccc.org/ https://www.ioccc.org/
- beyondCritics 6y agoEither you love C++ or you hate it. To tell the truth, i am also of the opinion that C++ is fucking crazy complicated. There are youtube videos from leading experts, explaining the usage of simple language elements at length, something like that is unheard of in modern languages. E.g. you are not expected to grasp overload resolution to the fullest extent: https://en.cppreference.com/w/cpp/language/overload_resolution https://en.cppreference.com/w/cpp/language/overload_resoluti... Mastery takes likely years of experience.
- pooya13 6y ago> Both C and C++ follow the same philosopy: "Trust the programmer" I disagree. I think ever since it’s inception from C, C++ has tried to increase type safety and continuously move more of the work to the compiler (latest example is concepts). It does empower the programmer to do what they want: OOP, FP, GP... The philosophy of the language is mostly about abstractions. Abstracting objects, types, resource management etc And using modern C++ features and a recent compiler makes it harder to make mistakes. Using some generally accepted guidelines and static analysis tools helps even further. Though the syntax is at times ugly due to the age of the language and it has a lot of inertia that makes it hard to get rid of some bad design decisions like some of the defaults, unless someone recreates c++ with the same flexibility and power, and the same powerful compilers/tools but with better syntax and defaults I don’t see the language going anywhere. And I am not holding my breath for another language to quickly be able to reproduce the C++ echo system that have taken decades to develop.
- srg0 6y agoThe philosophy of C++ is about _zero cost_ abstractions.
- 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.