6 ms·

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

by 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.)
    - ryanmolden 14y ago
      I don't disagree about aliasing, but a print function shouldn't be taking ref to a non-const anything anyways, it should have no need to mutate the vector. You can't clear through a ref to const. Your general point holds but I would say I have probably written/found very few aliasing bugs in C++ over the years, it just doesn't seem to arise often, perhaps your experience differs. Alas there are few ways to prevent dedicated folks from writing really ill-advised code.
    - 14y ago

by daivd 14y ago

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.)
  - ryanmolden 14y ago
    I don't disagree about aliasing, but a print function shouldn't be taking ref to a non-const anything anyways, it should have no need to mutate the vector. You can't clear through a ref to const. Your general point holds but I would say I have probably written/found very few aliasing bugs in C++ over the years, it just doesn't seem to arise often, perhaps your experience differs. Alas there are few ways to prevent dedicated folks from writing really ill-advised code.
  - 14y ago