7 ms·

C++ is a very poorly designed language. A lot of the work being done by the committees is fixing Stroustrup's mistakes. Consider horrors such as this. In the f

C++ is a very poorly designed language. A lot of the work being done by the committees is fixing Stroustrup's mistakes. Consider horrors such as this. In the following statement what are foo and bar? int x = foo(2) + bar(3); Most people will say foo and bar are functions and that's a reasonable guess. Unless you are talking about C++. In C++ foo and bar could be functions but could also lots of other things. For example it could be the equivalent of the statement below: int x = (foo)2 + (bar)3; In other words type casting can be written as (foo)2 or as foo(2). Just to make it harder to understand what is going on. As another example consider implicit type conversions: Foo b = c + 3; If 3 is not compatible with whatever type c is then C++ checks if there is a constructor that accepts an int parameter, and it automatically calls the constructor to convert 3 to the appropriate type. Many of these craziness is being addressed by standards committees. C++ as designed by Stroustrup is a horrible language. Just look at his C++ book. It is huge and heavy and in fact Stroustrup takes pride in how big and complex the language is. C is an awesome language. C++ is horrible.

api 6y ago
This weird ambiguous syntax exists to allow among other things templates that take either primitive or class types. It makes primitive types usable as if they are classes with copy constructors. That being said, it can certainly be ugly. A lot of the ugliness comes from trying to maintain itself as a mostly superset of C. Technically it no longer is strictly that, but most C code will compile fine in a C++ source file.
pmoriarty 6y ago
"Most people will say foo and bar are functions and that's a reasonable guess. Unless you are talking about C++. In C++ foo and bar could be functions but could also lots of other things." Same as in Lisp, one of the most beloved of languages on HN. Were Lisp's macros a mistake? Some will say yes, but overall the language is more praised for them than damned. So highly regarded are Lisp macros that many languages will eagerly proclaim that they have macros too -- even if they're not homoiconic and so harder to work with than in Lisp. Few if any are the languages that proudly proclaim that they don't have macros because they thought Lisp macros were a big mistake. C++ fans themselves often point out that C++ templates can be as powerful as Lisp macros. So which is it? Is giving users the power to radically transform their language a bug or a feature?
- ajkjk 6y ago
  I don't think lisp is that beloved here. It's just that the few people who love it love to bring it up.
  - saagarjha 6y ago
    Hacker News is written in a Lisp, started by people deeply interested in the language, and frequented in a large part by people who feel similarly.
    - ajkjk 6y ago
      I think that last clause is incorrect. It might have once been correct but I suspect most people on here have never used Lisp at all.
- jnxx 6y ago
  This is perhaps a misunderstanding. Lisp macros are a part of the language. Of course you can use them to make your code unreadable. But what they are used for is to evolve and add definitions for things such as iteration, which in other languages, like Python or C++ is not possible without a language change. For example: https://lispcookbook.github.io/cl-cookbook/iteration.html https://lispcookbook.github.io/cl-cookbook/iteration.html https://docs.racket-lang.org/reference/for.html https://docs.racket-lang.org/reference/for.html
29athrowaway 6y ago
If you mark the constructor as explicit, the automatic cast you mention does not take place and you'll get a compile time error. The casting style can be enforced via linting. There are also C++ cast operators, that in my opinion should be preferred to the C style casts: static_cast, dynamic_cast, reinterpret_cast, const_cast, static_pointer, dynamic_pointer_cast, const_pointer_cast... and you can enforce that those are preferred rather than C style casts.
beyondCritics 6y ago
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/
    - 6y ago
jeffbee 6y ago
I mean, it's even more weird than you said. It's not impossible that Foo(int) and (int)Foo or int g = foo do completely different things. Foo could define an `operator int` that terminates the program, or does any damn thing.
john_moscow 6y ago
>In other words type casting can be written as (foo)2 or as foo(2). Just to make it harder to understand what is going on. Or to make it easy to describe high-level behavior where you don't care about the details. In your example, foo and bar could be some complex vector or matrix types with custom allocation/deallocation logic. So this line: int x = foo(2) + bar(3); Is an equivalent of 7 lines in Plain C: foo tmp_foo; bar tmp_bar; construct_foo_from_int(&tmp_foo, 2); construct_bar_from_int(&tmp_bar, 3); int x = add_foo_and_bar(&tmp_foo, &tmp_bar); free_foo(&tmp_foo); free_bar(&tmp_bar); Sure, if you don't know what foo and bar are, it's confusing. But if you want to decompose what you are doing from how you are doing it, this syntax rocks. BTW, (foo)2 syntax is preserved for backward compatibility with C and is deprecated in favor of static/dynamic/reinterpret_cast<>() (that many people don't use due to clunkiness) and foo(2) is unavoidable if foo's constructor has more than 1 argument.
giomasce 6y ago
Well, constructors are not very different from functions, from the caller point of view. Also, Python is much worse in this: any call can be monkey patched at basically any point during the execution, but people do not (usually) use this as an example of poor language designing. You expect the programmer to use the language features considerately. BTW, in C++ every call is resolved at compile time, and the compiler could tell you what you are exactly doing at each line, including whether your examples are function calls or casts. If you dump the right table in GCC the information is there, although it's a pity there is no convenient way to access it. Cppexplorer helps a little bit, but I always find it difficult to understand. It's a problem of tooling, though, the language is well defined.
- formerly_proven 6y ago
  > If you dump the right table in GCC the information is there, although it's a pity there is no convenient way to access it. CLion, ctrl+B.
barumi 6y ago
> Consider horrors such as this. In the following statement what are foo and bar? I don't understand your point. What's exactly the problem of knowing what are foo and bar? Even if you struggle with C++, any half decent IDE allows you to check the symbol and see what's being called with a single mouse click. So what's exactly the problem? > As another example consider implicit type conversions: Again, what's exactly the problem? If you write down "c+3" it's your responsibility to know what you are doing and that "c+3" does make sense. And your example can only start to become a possibility if you explicitly and quite intentionally define your constructors to allow implicit type conversions, which is a direct violation of basic C++ best practices. Adding to that, your convoluted example is no where near the mess that's javascript or Python and somehow people manage to not screw that up even without any type checking. So why single out C++ although it does provide all sorts of guardrails and sanity checks? > Many of these craziness You failed to show any semblance of "craziness" in any of the convoluted examples you presented. In fact, you only showed you struggle with a language you barely have any experience with, let alone a grasp on rudimentary best practices such as requiring explicit constructors. Thus, why pin the blame on the language instead of where it really belongs: your lack of knowledge and experience using the language?
gpderetta 6y ago
Thanks to macros foo(2) can be litterally anything in awesome C.

api 6y ago

This weird ambiguous syntax exists to allow among other things templates that take either primitive or class types. It makes primitive types usable as if they are classes with copy constructors. That being said, it can certainly be ugly. A lot of the ugliness comes from trying to maintain itself as a mostly superset of C. Technically it no longer is strictly that, but most C code will compile fine in a C++ source file.

pmoriarty 6y ago

"Most people will say foo and bar are functions and that's a reasonable guess. Unless you are talking about C++. In C++ foo and bar could be functions but could also lots of other things." Same as in Lisp, one of the most beloved of languages on HN. Were Lisp's macros a mistake? Some will say yes, but overall the language is more praised for them than damned. So highly regarded are Lisp macros that many languages will eagerly proclaim that they have macros too -- even if they're not homoiconic and so harder to work with than in Lisp. Few if any are the languages that proudly proclaim that they don't have macros because they thought Lisp macros were a big mistake. C++ fans themselves often point out that C++ templates can be as powerful as Lisp macros. So which is it? Is giving users the power to radically transform their language a bug or a feature?

ajkjk 6y ago
I don't think lisp is that beloved here. It's just that the few people who love it love to bring it up.
- saagarjha 6y ago
  Hacker News is written in a Lisp, started by people deeply interested in the language, and frequented in a large part by people who feel similarly.
  - ajkjk 6y ago
    I think that last clause is incorrect. It might have once been correct but I suspect most people on here have never used Lisp at all.
jnxx 6y ago
This is perhaps a misunderstanding. Lisp macros are a part of the language. Of course you can use them to make your code unreadable. But what they are used for is to evolve and add definitions for things such as iteration, which in other languages, like Python or C++ is not possible without a language change. For example: https://lispcookbook.github.io/cl-cookbook/iteration.html https://lispcookbook.github.io/cl-cookbook/iteration.html https://docs.racket-lang.org/reference/for.html https://docs.racket-lang.org/reference/for.html

29athrowaway 6y ago

If you mark the constructor as explicit, the automatic cast you mention does not take place and you'll get a compile time error. The casting style can be enforced via linting. There are also C++ cast operators, that in my opinion should be preferred to the C style casts: static_cast, dynamic_cast, reinterpret_cast, const_cast, static_pointer, dynamic_pointer_cast, const_pointer_cast... and you can enforce that those are preferred rather than C style casts.

beyondCritics 6y ago

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/
  - 6y ago

jeffbee 6y ago

I mean, it's even more weird than you said. It's not impossible that Foo(int) and (int)Foo or int g = foo do completely different things. Foo could define an `operator int` that terminates the program, or does any damn thing.

john_moscow 6y ago

>In other words type casting can be written as (foo)2 or as foo(2). Just to make it harder to understand what is going on. Or to make it easy to describe high-level behavior where you don't care about the details. In your example, foo and bar could be some complex vector or matrix types with custom allocation/deallocation logic. So this line: int x = foo(2) + bar(3); Is an equivalent of 7 lines in Plain C: foo tmp_foo; bar tmp_bar; construct_foo_from_int(&tmp_foo, 2); construct_bar_from_int(&tmp_bar, 3); int x = add_foo_and_bar(&tmp_foo, &tmp_bar); free_foo(&tmp_foo); free_bar(&tmp_bar); Sure, if you don't know what foo and bar are, it's confusing. But if you want to decompose what you are doing from how you are doing it, this syntax rocks. BTW, (foo)2 syntax is preserved for backward compatibility with C and is deprecated in favor of static/dynamic/reinterpret_cast<>() (that many people don't use due to clunkiness) and foo(2) is unavoidable if foo's constructor has more than 1 argument.

giomasce 6y ago

Well, constructors are not very different from functions, from the caller point of view. Also, Python is much worse in this: any call can be monkey patched at basically any point during the execution, but people do not (usually) use this as an example of poor language designing. You expect the programmer to use the language features considerately. BTW, in C++ every call is resolved at compile time, and the compiler could tell you what you are exactly doing at each line, including whether your examples are function calls or casts. If you dump the right table in GCC the information is there, although it's a pity there is no convenient way to access it. Cppexplorer helps a little bit, but I always find it difficult to understand. It's a problem of tooling, though, the language is well defined.

formerly_proven 6y ago
> If you dump the right table in GCC the information is there, although it's a pity there is no convenient way to access it. CLion, ctrl+B.

barumi 6y ago

> Consider horrors such as this. In the following statement what are foo and bar? I don't understand your point. What's exactly the problem of knowing what are foo and bar? Even if you struggle with C++, any half decent IDE allows you to check the symbol and see what's being called with a single mouse click. So what's exactly the problem? > As another example consider implicit type conversions: Again, what's exactly the problem? If you write down "c+3" it's your responsibility to know what you are doing and that "c+3" does make sense. And your example can only start to become a possibility if you explicitly and quite intentionally define your constructors to allow implicit type conversions, which is a direct violation of basic C++ best practices. Adding to that, your convoluted example is no where near the mess that's javascript or Python and somehow people manage to not screw that up even without any type checking. So why single out C++ although it does provide all sorts of guardrails and sanity checks? > Many of these craziness You failed to show any semblance of "craziness" in any of the convoluted examples you presented. In fact, you only showed you struggle with a language you barely have any experience with, let alone a grasp on rudimentary best practices such as requiring explicit constructors. Thus, why pin the blame on the language instead of where it really belongs: your lack of knowledge and experience using the language?

gpderetta 6y ago

Thanks to macros foo(2) can be litterally anything in awesome C.