5 ms·

Wow, as somebody who has "seriously" worked with C++ professionally since ~5years and with more "user friendly" languages since decades, these new features don'

by ktpsns 8y ago

Wow, as somebody who has "seriously" worked with C++ professionally since ~5years and with more "user friendly" languages since decades, these new features don't blow me out of the socks. Conversely, I'm terrified by the super complex syntax of these examples. Sure, these are synthetical border cases, but it shows the abysses of C++ logic. I get headache already with error messages from contemporary C++ templating and don't even got my hands touched with error messages from future templated lambdas à la C++...

shereadsthenews 8y ago
Some of them are complex, some are less complex than they used to be. For example look at the first article in this series that discusses the very common mistake of incorrect parameter types leading to unwanted copies, which is solved by generic lambdas where the compiler is permitted to deduce the type. std::map<std::string, int> numbers { { "one", 1 }, {"two", 2 }, { "three", 3 } }; // each time entry is copied from pair<const string, int>! std::for_each(std::begin(numbers), std::end(numbers), [](const std::pair<std::string, int>& entry) { std::cout << entry.first << " = " << entry.second << '\n'; } ); This has an error, which is harder to commit in c++14 and forward, with a more compact expression: std::for_each(std::begin(numbers), std::end(numbers), [](const auto& entry) { std::cout << entry.first << " = " << entry.second << '\n'; } );
- deleted 8y ago
  [deleted]
- mehrdadn 8y ago
  In all honesty in my experience both of these approaches are wrong. Rather, it's using the good ol' typedef, which you should already be using pretty liberally anyway: typedef std::map<std::string, int> Numbers; Numbers numbers { { "one", 1 }, {"two", 2 }, { "three", 3 } }; // each time entry is copied from pair<const string, int>! std::for_each(std::begin(numbers), std::end(numbers), [](const Numbers::value_type& entry) { std::cout << entry.first << " = " << entry.second << '\n'; } ); Or if you're feeling particularly pedantically correct, you can replace const Numbers::value_type& with Numbers::const_reference, but I don't go that far generally. IMHO one of the mistakes of (many, even very experienced) C++ programmers is that they don't realize typedefs are such a powerful tool to be used liberally throughout a code base, and they instead overuse auto and decltype. Typedefs prevent you from repeating yourself, prevent accidents like these, make changing the underlying types a breeze, are self-documenting, and (when needed on occasion) let you use a different type for a variable than the expression used to initialize it, which isn't possible with auto.
deleted 8y ago
[deleted]
kllrnohj 8y ago
What new syntax? And what specifically is "super complex syntax" in these examples? Are you referring to the C++20 changes with those statements, or are you still stuck on C++11's changes? And a few of the examples are about how template errors will become less complex not more.
danbolt 8y ago
At someone who professionally works with relatively modern C++ (eg: C++14/17) and originally learned C++98, it's not as difficult once you get into the headspace of it. I'd definitely prefer writing in OCaml every day if I could, but I can understand why a lot of C++ is the way it is, and having the newer features is an improvement on the day-to-day.
- notacoward 8y ago
  > it's not as difficult once you get into the headspace of it. The same could be said of APL, PHP, or Brainfuck. Having to get into the headspace of C++ is one of the language's weaknesses. A true high-level language doesn't force programmers to spend half their time thinking about how the compiler internals deal with lvalues vs. rvalues, move semantics, decision trees for choosing which promotion or operator overload to do, and so on ad nauseam. Compilers are supposed to be assistants, there to relieve programmers of some drudgery, but C++ compilers are always like malicious assistants determined to do the opposite whenever they can. It's often more work getting them to do the right thing than to do it yourself in Plain Old C - which is what I'd rather do if I can't use a better high-level language than C++.
  - danbolt 8y ago
    I agree that the act of submerging oneself into C++ is really a frustration about the language. It's a lot like using APL or Brainfuck as you mention and getting into gear. Still, I wouldn't say that C++ is a "true high-level language" or tries to be based on the reasons you mention. It's purpose is wide-ranging, but being closer to the metal than something like Ruby, C#, or Julia. And regardless, I think there are a lot of contexts where C++'s features can give productivity benefits over the time spent working through the hard spots. That's going to be pretty subjective though. Based on what you mention though, I'd encourage you to use "Plain Old C" (ANSI, C99, or C11?) if it helps you be more productive. I can imagine with more and more languages fitting the that semi low-level space (eg: Rust and Zig) coming on the scene, there's a lot more opportunity to find the right tool than ever before.
    - 8y ago
maxxxxx 8y ago
It seems to me that C++ has always been a language where you really need to understand each statement you use and its implications. Otherwise you can quickly get in trouble. So I think C++ should either be close to a full time job where you have to learn all the details or you probably shouldn't do it.
- 0815test 8y ago
  Yes, exactly. And this is why people who say that Rust is too difficult and complicated to ever get traction have no idea what "difficult and complicated" even means in this part of our industry. The whole point of projects like Rust is to make these things a lot simpler and easier to get correct, and thus to empower everyone to write better code.

by ktpsns 8y ago

shereadsthenews 8y ago

Some of them are complex, some are less complex than they used to be. For example look at the first article in this series that discusses the very common mistake of incorrect parameter types leading to unwanted copies, which is solved by generic lambdas where the compiler is permitted to deduce the type. std::map<std::string, int> numbers { { "one", 1 }, {"two", 2 }, { "three", 3 } }; // each time entry is copied from pair<const string, int>! std::for_each(std::begin(numbers), std::end(numbers), [](const std::pair<std::string, int>& entry) { std::cout << entry.first << " = " << entry.second << '\n'; } ); This has an error, which is harder to commit in c++14 and forward, with a more compact expression: std::for_each(std::begin(numbers), std::end(numbers), [](const auto& entry) { std::cout << entry.first << " = " << entry.second << '\n'; } );

deleted 8y ago
[deleted]
mehrdadn 8y ago
In all honesty in my experience both of these approaches are wrong. Rather, it's using the good ol' typedef, which you should already be using pretty liberally anyway: typedef std::map<std::string, int> Numbers; Numbers numbers { { "one", 1 }, {"two", 2 }, { "three", 3 } }; // each time entry is copied from pair<const string, int>! std::for_each(std::begin(numbers), std::end(numbers), [](const Numbers::value_type& entry) { std::cout << entry.first << " = " << entry.second << '\n'; } ); Or if you're feeling particularly pedantically correct, you can replace const Numbers::value_type& with Numbers::const_reference, but I don't go that far generally. IMHO one of the mistakes of (many, even very experienced) C++ programmers is that they don't realize typedefs are such a powerful tool to be used liberally throughout a code base, and they instead overuse auto and decltype. Typedefs prevent you from repeating yourself, prevent accidents like these, make changing the underlying types a breeze, are self-documenting, and (when needed on occasion) let you use a different type for a variable than the expression used to initialize it, which isn't possible with auto.

deleted 8y ago

[deleted]

kllrnohj 8y ago

What new syntax? And what specifically is "super complex syntax" in these examples? Are you referring to the C++20 changes with those statements, or are you still stuck on C++11's changes? And a few of the examples are about how template errors will become less complex not more.

danbolt 8y ago

At someone who professionally works with relatively modern C++ (eg: C++14/17) and originally learned C++98, it's not as difficult once you get into the headspace of it. I'd definitely prefer writing in OCaml every day if I could, but I can understand why a lot of C++ is the way it is, and having the newer features is an improvement on the day-to-day.

notacoward 8y ago
> it's not as difficult once you get into the headspace of it. The same could be said of APL, PHP, or Brainfuck. Having to get into the headspace of C++ is one of the language's weaknesses. A true high-level language doesn't force programmers to spend half their time thinking about how the compiler internals deal with lvalues vs. rvalues, move semantics, decision trees for choosing which promotion or operator overload to do, and so on ad nauseam. Compilers are supposed to be assistants, there to relieve programmers of some drudgery, but C++ compilers are always like malicious assistants determined to do the opposite whenever they can. It's often more work getting them to do the right thing than to do it yourself in Plain Old C - which is what I'd rather do if I can't use a better high-level language than C++.
- danbolt 8y ago
  I agree that the act of submerging oneself into C++ is really a frustration about the language. It's a lot like using APL or Brainfuck as you mention and getting into gear. Still, I wouldn't say that C++ is a "true high-level language" or tries to be based on the reasons you mention. It's purpose is wide-ranging, but being closer to the metal than something like Ruby, C#, or Julia. And regardless, I think there are a lot of contexts where C++'s features can give productivity benefits over the time spent working through the hard spots. That's going to be pretty subjective though. Based on what you mention though, I'd encourage you to use "Plain Old C" (ANSI, C99, or C11?) if it helps you be more productive. I can imagine with more and more languages fitting the that semi low-level space (eg: Rust and Zig) coming on the scene, there's a lot more opportunity to find the right tool than ever before.
  - 8y ago

maxxxxx 8y ago

It seems to me that C++ has always been a language where you really need to understand each statement you use and its implications. Otherwise you can quickly get in trouble. So I think C++ should either be close to a full time job where you have to learn all the details or you probably shouldn't do it.

0815test 8y ago
Yes, exactly. And this is why people who say that Rust is too difficult and complicated to ever get traction have no idea what "difficult and complicated" even means in this part of our industry. The whole point of projects like Rust is to make these things a lot simpler and easier to get correct, and thus to empower everyone to write better code.