5 ms·

I'm learning Python and I must say it is a wonderful language. Being able to concatenate strings by simply saying "a + b" is a great productivity boost (coming

I'm learning Python and I must say it is a wonderful language. Being able to concatenate strings by simply saying "a + b" is a great productivity boost (coming from C++). Python libraries are powerful. I can read an Excel spreadsheet with one line of code. I can create plots in PDF format with a half-dozen lines. Amazing! However, I am disappointed with the difficulty of turning a program into a Windows EXE. I wrote a small program (couple of thousand lines), tried Py2exe which failed to handle the Numpy (or Matplotlib, I forget which) imbroglio. PyInstaller works, except that the EXE is 85MB, and takes one minute to start up. Not practical for customer distribution. I can't expect my customers to install the Python runtime. In contrast, my 500KLOC C++ program, with all its third-party libraries, is 19MB. Yes, I know, Python needs everything including the kitchen sink. Still, 85MB is not practical. Too bad. Not all programs run on a server.

alexchamberlain 12y ago
I love Python too... but, I love C++ as well... http://en.cppreference.com/w/cpp/string/basic_string/operator%2B http://en.cppreference.com/w/cpp/string/basic_string/operato...
theseoafs 12y ago
> Being able to concatenate strings by simply saying "a + b" is a great productivity boost (coming from C++) C++ has had this operator overloaded for strings for decades. With regard to the size of compiled executables, I can't really say much except "that's not what it's made for". If you need to ship compiled executables to people, Python is an extraordinarily inappropriate choice; stick with C++.
- dkersten 12y ago
  I've often heard it said that if you're not using std::string for strings in C++, you're (arguably) not using C++
  - GnarfGnarf 12y ago
    I just did a test using std:: and old-fashioned char[]. The fancy std:: is fifteen times slower than the strcat(). In a loop with intensive string manipulation, this could cause the program to get back to you in 15 seconds instead of 1 second. You don't mind waiting? Here's the code (Visual Studio 2010): #include <string> #include <time.h> char buf[64], buf2[64]; clock_t start = clock(); for(i = 0; i < 100000; i++) { _snprintf(buf, sizeof(buf), "%d", i); _snprintf(buf2, sizeof(buf2), "%d", i * i); #if defined FAST strcat(buf, buf2); #else std::string s1 = buf; std::string s2 = buf2; std::string s3 = s1 + s2; #endif } _snprintf(buf, sizeof(buf), "%.4f\n", (float)(clock() - start) / (float)CLK_TCK); OutputDebugString(buf);
    - theseoafs 12y ago
      You should be using `+=` to build strings incrementally in C++, not using `+` repeatedly.
    - 30thElement 12y ago
      Well of course you're getting a speed difference, look at how much extra work you're doing in the std::string code! The char[64]s are allocated once but you reallocate the std::strings every time. By pulling the declaration of s1, s2, and s3 to the top, I'm getting equivalent speed (g++ 4.4.7 with -g, 0.02s each time, clock() isn't any more accurate). And for essentially no runtime cost, you're getting memory safety and exception safety. C++ is all about low-cost abstractions. Any speed difference between the C++ way and the C way should be very small, and the C++ way is safer. Use std::string (and std::vector and all the rest) unless you have a very good reason not too, and then you should probably just write your own custom implementation. Reverting to the C way is just asking for issues.
      - GnarfGnarf 12y ago
        I moved the std::string allocation outside the loop, now it's only ten times slower. I'm all for using abstractions and working smarter, but why pay such a performance penalty?
- ma2rten 12y ago
  Dropbox seems to be doing ok shipping python to customers.
  - koshak 12y ago
    If they were ok why should they had forked python?
- PythonicAlpha 12y ago
  Might be, but in Python it is much easier to use and better integrated in the language basics. Operator overloading is something, that belongs to the 'pro' skill-set of C++ developers and done wrong, can lead to many problems. In Python it is much easier to overwrite the behavior of such standard methods and the language core can be learned in about 1/4 of the time you need to learn in C++ to just know the basics (C core, C++ object basics, Operator overloading, standard library basics like the string class, ...) -- in Python you get the power with much less learning effort and without the technical troubles.
zem 12y ago
you might like D -it's worth a look at the least. likewise go and nimrod, which also aim for better programmer productivity combined with compilation to efficient native code
Shorel 12y ago
You may want to try D. The template syntax is a great productivity boost compared to C++.

alexchamberlain 12y ago

I love Python too... but, I love C++ as well... http://en.cppreference.com/w/cpp/string/basic_string/operator%2B http://en.cppreference.com/w/cpp/string/basic_string/operato...

theseoafs 12y ago

> Being able to concatenate strings by simply saying "a + b" is a great productivity boost (coming from C++) C++ has had this operator overloaded for strings for decades. With regard to the size of compiled executables, I can't really say much except "that's not what it's made for". If you need to ship compiled executables to people, Python is an extraordinarily inappropriate choice; stick with C++.

dkersten 12y ago
I've often heard it said that if you're not using std::string for strings in C++, you're (arguably) not using C++
- GnarfGnarf 12y ago
  I just did a test using std:: and old-fashioned char[]. The fancy std:: is fifteen times slower than the strcat(). In a loop with intensive string manipulation, this could cause the program to get back to you in 15 seconds instead of 1 second. You don't mind waiting? Here's the code (Visual Studio 2010): #include <string> #include <time.h> char buf[64], buf2[64]; clock_t start = clock(); for(i = 0; i < 100000; i++) { _snprintf(buf, sizeof(buf), "%d", i); _snprintf(buf2, sizeof(buf2), "%d", i * i); #if defined FAST strcat(buf, buf2); #else std::string s1 = buf; std::string s2 = buf2; std::string s3 = s1 + s2; #endif } _snprintf(buf, sizeof(buf), "%.4f\n", (float)(clock() - start) / (float)CLK_TCK); OutputDebugString(buf);
  - theseoafs 12y ago
    You should be using `+=` to build strings incrementally in C++, not using `+` repeatedly.
  - 30thElement 12y ago
    Well of course you're getting a speed difference, look at how much extra work you're doing in the std::string code! The char[64]s are allocated once but you reallocate the std::strings every time. By pulling the declaration of s1, s2, and s3 to the top, I'm getting equivalent speed (g++ 4.4.7 with -g, 0.02s each time, clock() isn't any more accurate). And for essentially no runtime cost, you're getting memory safety and exception safety. C++ is all about low-cost abstractions. Any speed difference between the C++ way and the C way should be very small, and the C++ way is safer. Use std::string (and std::vector and all the rest) unless you have a very good reason not too, and then you should probably just write your own custom implementation. Reverting to the C way is just asking for issues.
    - GnarfGnarf 12y ago
      I moved the std::string allocation outside the loop, now it's only ten times slower. I'm all for using abstractions and working smarter, but why pay such a performance penalty?
ma2rten 12y ago
Dropbox seems to be doing ok shipping python to customers.
- koshak 12y ago
  If they were ok why should they had forked python?
PythonicAlpha 12y ago
Might be, but in Python it is much easier to use and better integrated in the language basics. Operator overloading is something, that belongs to the 'pro' skill-set of C++ developers and done wrong, can lead to many problems. In Python it is much easier to overwrite the behavior of such standard methods and the language core can be learned in about 1/4 of the time you need to learn in C++ to just know the basics (C core, C++ object basics, Operator overloading, standard library basics like the string class, ...) -- in Python you get the power with much less learning effort and without the technical troubles.

zem 12y ago

you might like D -it's worth a look at the least. likewise go and nimrod, which also aim for better programmer productivity combined with compilation to efficient native code

Shorel 12y ago

You may want to try D. The template syntax is a great productivity boost compared to C++.