4 ms·

This story about the committees fixing Stroustrup's "mistakes" is completely made up from you and is not even remotely true. Also Stroustrup does _not_ take pri

This story about the committees fixing Stroustrup's "mistakes" is completely made up from you and is not even remotely true. Also Stroustrup does _not_ take pride in how big the language is, the exact opposite is true. E.g. you will never ever hear Stroustrup speaking about template meta programming or similar weird stuff. He always tries to teach the practical side of C++. His C++ book is not big because the language is complex, but because it is a genral introduction into programming with C++. In fact, if you want to learn the esoteric features of C++, you have to buy other books. Implicit type conversions are inherited from C, the language you called "awesome". Many arcane features of C are nowadays considered as anachronisms and no modern designed language would repeat them.

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 ago
  C 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 ago
    Either 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 ago
      The 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 ago
    The second case is easily solved by having an overload operator+(complex lhs, int rhs). No need to convert anything.
    - brianush1 6y ago
      complex 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 ago
        Haskell 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 ago
        C++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.

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 ago
C 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 ago
  Either 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 ago
    The 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 ago
  The second case is easily solved by having an overload operator+(complex lhs, int rhs). No need to convert anything.
  - brianush1 6y ago
    complex 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 ago
      Haskell 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 ago
        C++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.