3 ms·

Whoever reads this , note that its a very outdated rant (although some parts are still true). > Well, the standard library doesn't have matrices or regular exp

Whoever reads this , note that its a very outdated rant (although some parts are still true). > Well, the standard library doesn't have matrices or regular expressions, either C++ does provide a standard regex library now, matrices can be made either with vectors or you can use boost libs for it. > The standard library doesn't support listing directories Same for filesystems, it now comes with the standard set of libraries For C++, it’s time and time again seen, that Boost libs are used as the experimentation stage to filter things and add to the C++ standard library, and boost is pretty feature rich with all sorts of utilities you might need to build a robust program. > In C++, things are different - there are no modules. C++20 is adding features related to modules support like in other programming languages (haskell, etc). Sure C++ is an old programming language with too many weird features, which end up hurting devs , but as long as you stick to the fine features. C++ is pretty fun to use. It has type inference now, those ugly looking long type-declarations, can easily be fixed by appropriate use of the “using” keyword in local scope (if you’re that worried about polluting the global namespace i.e) I think C++ gets unnecessary hate , every language has its quirks, you just avoid the bad stuff and stick with the good bits.

spoiler 5y ago
I don't think anyone hates C++, they hate how it makes them feel when they have to work in it. Also, I think it's a bit ludicrous to say "just use a subset" because there's no definitive guide to "sane" or safe subset. Also, regarding boost: I'm extremely conflicted about it... On one hand, it's made my life easier, but on the other it feels like once you add it to the codebase it metastases everywhere; it's not a C++ codebase anymote, but a boost codebase. Also, it ill-composes with most things that aren't boost (and sometimes even within other parts of boost, because boost is an amalgamation of libraries)
xigoi 5y ago
It's 2002 and `import <iostream>;` still doesn't compile.
tsimionescu 5y ago
> I think C++ gets unnecessary hate , every language has its quirks, you just avoid the bad stuff and stick with the good bits. C++ is the single most complex programming language ever devised. I don't think it deserves hate per se, but it there is no other language as hard to learn, as hard to write safe code for, and as hard to read. Even your example of type inference is actually very hard to learn. If I do `auto x = 7;` will x be const or not? If I have `const int &y = 7; auto x = y;` will x be const int? int? const int&? What if it's a pointer, or volatile instead?
- teitoklien 5y ago
  The problems you mentioned about type inference are valid, but this issue lies is any programming language which provides this feature, and a lot of languages which are promoted and looked upto on HN (like Haskell) heavily use type inference. The simplest answer to your question of how to know what type the compiler will choose for type inferenced variables, is by compiling an example code snippet and printing out the type using either something like decltype or typeid (preferably the former). But the thing is, the point of type inference is you want to abstract away the type, if you want to explicitly be aware of the type at all times, you should explicitly state it in declarations. The issues described is inherent in the very notion of letting the compiler infer the type for you, which leads to this ambiguity. If you want to avoid it, then best to be explicit, if you dont care about the type and are using typeinference to build compile time simple template functions using lambda and the type inferred parameters. Then type inference is pretty handy and leads to easy to read code. It’s a tool, when you feel it’s getting in your way at writing code, you remove the tool/feature from your code.
  - tsimionescu 5y ago
    > but this issue lies is any programming language which provides this feature, and a lot of languages which are promoted and looked upto on HN (like Haskell) heavily use type inference. > The issues described is inherent in the very notion of letting the compiler infer the type for you, which leads to this ambiguity. It's not the same thing. Types and type qualifiers are different things, and few languages have type qualifiers in the same way as C++. In fact, auto, unlike type inference in any other language, does NOT match the full type of the variable - that's why things like `volatile auto &x = y` exist. > But the thing is, the point of type inference is you want to abstract away the type That's the point in other languages. In C++ it's much more just shorthand for the horribly long type names you end up with in templates.

spoiler 5y ago

I don't think anyone hates C++, they hate how it makes them feel when they have to work in it. Also, I think it's a bit ludicrous to say "just use a subset" because there's no definitive guide to "sane" or safe subset. Also, regarding boost: I'm extremely conflicted about it... On one hand, it's made my life easier, but on the other it feels like once you add it to the codebase it metastases everywhere; it's not a C++ codebase anymote, but a boost codebase. Also, it ill-composes with most things that aren't boost (and sometimes even within other parts of boost, because boost is an amalgamation of libraries)

xigoi 5y ago

It's 2002 and `import <iostream>;` still doesn't compile.

tsimionescu 5y ago

> I think C++ gets unnecessary hate , every language has its quirks, you just avoid the bad stuff and stick with the good bits. C++ is the single most complex programming language ever devised. I don't think it deserves hate per se, but it there is no other language as hard to learn, as hard to write safe code for, and as hard to read. Even your example of type inference is actually very hard to learn. If I do `auto x = 7;` will x be const or not? If I have `const int &y = 7; auto x = y;` will x be const int? int? const int&? What if it's a pointer, or volatile instead?

teitoklien 5y ago
The problems you mentioned about type inference are valid, but this issue lies is any programming language which provides this feature, and a lot of languages which are promoted and looked upto on HN (like Haskell) heavily use type inference. The simplest answer to your question of how to know what type the compiler will choose for type inferenced variables, is by compiling an example code snippet and printing out the type using either something like decltype or typeid (preferably the former). But the thing is, the point of type inference is you want to abstract away the type, if you want to explicitly be aware of the type at all times, you should explicitly state it in declarations. The issues described is inherent in the very notion of letting the compiler infer the type for you, which leads to this ambiguity. If you want to avoid it, then best to be explicit, if you dont care about the type and are using typeinference to build compile time simple template functions using lambda and the type inferred parameters. Then type inference is pretty handy and leads to easy to read code. It’s a tool, when you feel it’s getting in your way at writing code, you remove the tool/feature from your code.
- tsimionescu 5y ago
  > but this issue lies is any programming language which provides this feature, and a lot of languages which are promoted and looked upto on HN (like Haskell) heavily use type inference. > The issues described is inherent in the very notion of letting the compiler infer the type for you, which leads to this ambiguity. It's not the same thing. Types and type qualifiers are different things, and few languages have type qualifiers in the same way as C++. In fact, auto, unlike type inference in any other language, does NOT match the full type of the variable - that's why things like `volatile auto &x = y` exist. > But the thing is, the point of type inference is you want to abstract away the type That's the point in other languages. In C++ it's much more just shorthand for the horribly long type names you end up with in templates.