5 ms·

Great post, it's always fun to see the cutting edge of C++ revealed. It's such a strange land. :) To me, this post would have been 10X more interesting if ther

by unwind 14y ago

Great post, it's always fun to see the cutting edge of C++ revealed. It's such a strange land. :) To me, this post would have been 10X more interesting if there was some elementary benchmarking included. If it's about the same speed as the corresponding Python code, which I'd bet is easier to write for more programmers, then I don't quite see the point being as clearly proven. If it's 100 times faster (or whatever), then it gives more credibility to the idea of writing code like this in C++ to begin with, and to learning all the new language features that makes it safe while being that much faster than Python.

michaelfeathers 14y ago
The simplifications are nice, but the problem is that the language still carries all of the heavy syntactic machinery that makes it happen, and there's nothing that prevents people from dipping down into it.
potkor 14y ago
Especially if the benchmark measured programming and debugging time.
daivd 14y ago
I wrote this post. The program is I/O-bound, so the only speed improvement comes from not having to start up the Python interpreter. If the task was CPU bound, you would get a great performance boost (sometimes 100x over CPython), but that is well known. There can be other reasons than performance for writing in C++. Used well, the strong static type system can catch many bugs. I suspect (but I cannot prove) that it could be almost as good as Haskell. I use Python for most things, though, so I don't really advocating switching to C++ for every little scripting task.
- unwind 14y ago
  D'oh, it (of course) makes total sense for this to be I/O bound, I didn't read the code too closely or I hope I would have figured out that much. Thanks for the clarification.
- alpatters 14y ago
  I do both python and C++ in my job. They're both great at what they do IMO. Often, they are a good match for each other; several of the boost libs have been designed similarly to python equivalent. boost python also makes writing python extensions very easy. For other reasons to write in C++ (or any static typed lang), I'd add type dispatching: calling different methods based on type. I also hate having a typo in a method name throwing at runtime. I also often convert python implementations to C++, often using boost, usually for performance in one part of the code. You can quite often get the same implementation in a similar number of lines, especially since C++11 with boost.
- deleted 14y ago
  [deleted]
- pcwalton 14y ago
  It won't be as good as Haskell for memory safety. For example, this program, using only C++11 idioms, crashes: #include <iostream> #include <vector> int main() { std::vector<std::string> v; v.push_back(std::string("Hello")); v.push_back(std::string("there")); for (auto ii = v.begin(), ie = v.end(); ii != ie; ++ii) { v.clear(); std::cout << *ii << std::endl; } return 0; } Preventing this sort of thing requires strong guarantees about aliasing (to ensure that "v" can't alias the vector being iterated over), which the C++ type system can't help you with.
  - evincarofautumn 14y ago
    “C++11 idioms” include a preference for immutability, which leads to natural factorings. You don’t have to worry about things like iterator invalidation that way. #include <algorithm> #include <iostream> #include <iterator> #include <vector> using namespace std; template<class T> void print(const T& v) { copy(begin(v), end(v), ostream_iterator<string>(cout, "\n")); } int main(int argc, char** argv) { vector<string> v{"Hello", "there"}; print(v); } Also, Haskell is only so safe—at work we’ve taken to rejecting non-total functions in review, because they cause more hassle than they’re worth. By non-total, I refer more to “error” than non-termination, of course.
    - pcwalton 14y ago
      "const" doesn't help you in the presence of aliasing: #include <iostream> #include <vector> template<typename T,typename U> void print(const T& v, U& w) { for (auto ii = v.begin(), ie = v.end(); ii != ie; ++ii) { w.clear(); std::cout << *ii << std::endl; } } int main() { std::vector<std::string> v; v.push_back(std::string("Hello")); v.push_back(std::string("there")); print(v, v); return 0; } In general there are lots of ways to get non-const access to const data. You'd need a sophisticated form of whole-program alias analysis to eliminate the unsafety here. (Even if you didn't have the second "U& w" parameter, there are other potential ways that "print" could get non-const access to "v"; global variables, TLS, by accessing a member of "v", etc.)

by unwind 14y ago

michaelfeathers 14y ago

The simplifications are nice, but the problem is that the language still carries all of the heavy syntactic machinery that makes it happen, and there's nothing that prevents people from dipping down into it.

potkor 14y ago

Especially if the benchmark measured programming and debugging time.

daivd 14y ago

I wrote this post. The program is I/O-bound, so the only speed improvement comes from not having to start up the Python interpreter. If the task was CPU bound, you would get a great performance boost (sometimes 100x over CPython), but that is well known. There can be other reasons than performance for writing in C++. Used well, the strong static type system can catch many bugs. I suspect (but I cannot prove) that it could be almost as good as Haskell. I use Python for most things, though, so I don't really advocating switching to C++ for every little scripting task.

unwind 14y ago
D'oh, it (of course) makes total sense for this to be I/O bound, I didn't read the code too closely or I hope I would have figured out that much. Thanks for the clarification.
alpatters 14y ago
I do both python and C++ in my job. They're both great at what they do IMO. Often, they are a good match for each other; several of the boost libs have been designed similarly to python equivalent. boost python also makes writing python extensions very easy. For other reasons to write in C++ (or any static typed lang), I'd add type dispatching: calling different methods based on type. I also hate having a typo in a method name throwing at runtime. I also often convert python implementations to C++, often using boost, usually for performance in one part of the code. You can quite often get the same implementation in a similar number of lines, especially since C++11 with boost.
deleted 14y ago
[deleted]
pcwalton 14y ago
It won't be as good as Haskell for memory safety. For example, this program, using only C++11 idioms, crashes: #include <iostream> #include <vector> int main() { std::vector<std::string> v; v.push_back(std::string("Hello")); v.push_back(std::string("there")); for (auto ii = v.begin(), ie = v.end(); ii != ie; ++ii) { v.clear(); std::cout << *ii << std::endl; } return 0; } Preventing this sort of thing requires strong guarantees about aliasing (to ensure that "v" can't alias the vector being iterated over), which the C++ type system can't help you with.
- evincarofautumn 14y ago
  “C++11 idioms” include a preference for immutability, which leads to natural factorings. You don’t have to worry about things like iterator invalidation that way. #include <algorithm> #include <iostream> #include <iterator> #include <vector> using namespace std; template<class T> void print(const T& v) { copy(begin(v), end(v), ostream_iterator<string>(cout, "\n")); } int main(int argc, char** argv) { vector<string> v{"Hello", "there"}; print(v); } Also, Haskell is only so safe—at work we’ve taken to rejecting non-total functions in review, because they cause more hassle than they’re worth. By non-total, I refer more to “error” than non-termination, of course.
  - pcwalton 14y ago
    "const" doesn't help you in the presence of aliasing: #include <iostream> #include <vector> template<typename T,typename U> void print(const T& v, U& w) { for (auto ii = v.begin(), ie = v.end(); ii != ie; ++ii) { w.clear(); std::cout << *ii << std::endl; } } int main() { std::vector<std::string> v; v.push_back(std::string("Hello")); v.push_back(std::string("there")); print(v, v); return 0; } In general there are lots of ways to get non-const access to const data. You'd need a sophisticated form of whole-program alias analysis to eliminate the unsafety here. (Even if you didn't have the second "U& w" parameter, there are other potential ways that "print" could get non-const access to "v"; global variables, TLS, by accessing a member of "v", etc.)