5 ms·

I upvoted you twice, in case you care. You raise some good points; the problem is, they both point the way to using languages other than C++: You essentially a

by cbd1984 12y ago

I upvoted you twice, in case you care. You raise some good points; the problem is, they both point the way to using languages other than C++: You essentially advocate using a subset of C++ (everyone does, even Stroustrup), and the subset of C++ you advocate is the high-level one with a maximal amount of automatic resource management, whether by templates or RAII. OK, if I'm doing that, I obviously don't care about the manual resource management part of C++, so why shouldn't I use a language which gives me all of that and more? Are the performance gains from using that subset of C++ compared to something else even perceptible?

72deluxe 12y ago
Thanks for the upvotes. You are right about both of these subsets pointing to other languages; I had not thought about that! I myself throw pointers around all over the place because I am restricted by my Windows compiler (no C++11 features) and I don't do stupid things with them (and am a slow learner for new features...). I suppose the performance gains are negligible in simple applications but in performance critical applications they can make a difference - games, web servers etc. See how Facebook built their PHP to C++ interpreter for reduction in running costs and heating costs. PHP was more convenient to write (and PHP developers are cheaper to hire I presume) but I wouldn't welcome all programs being of the "interpreted" type. With C++, the push for type safety and making the compiler do the work for you will mean more efficient programs and less run-time checks. This is particularly important on mobile devices where processing usage = less battery life. And I would be far happier running an application for a few extra hours on my laptop if it was written in a sensible language and made efficient use of my hardware; lots of little performance gains add up. Imagine the horror of apps being written entirely for developer convenience with little thought to performance - you could kiss goodbye to a big stack of power worldwide. That problem is only going to get worse, and the "there's processing power so I'll use it" approach is what gave us bloatware in the first place. So I suppose application and system program development is a tradeoff between developer convenience and user convenience (battery life, speed etc.)
pyrois 12y ago
Good point! For me, I think the question here isn't so much "performance gains" as "interoperability, near-ubiquity, and staying power". For "interoperability", I'm just going to quote myself: "If you write your library in Perl, guess what, only people writing Perl will use it. If you write it in Java, well, maybe the Scala folk will wrap it up, or the Jython folk, but you won't get any people writing in Ruby to use it. If you write it in C++, you can provide efficient bindings to any of those languages." In terms of ubiquity, what I mean is that almost every platform has a standards-compliant-ish C++ compiler for it. And before people get in a tizzy, I mean weird platforms, not just computers with a browser installed. That's Intel, yes, but also DSPs, FPGAs, ARMs, and whole host of other chips. This didn't used to be true, but with LLVM, almost an entire standards-compliant C++ toolchain can be generated for your platform pretty easily. The exception tends to be, ironically enough, exceptions. They need to be special-cased for your chip, but still, C++ exists in places where the JVM doesn't dare go. And finally, for staying power, I'll quote myself again! "Look at FFmpeg or ImageMagick. They are libraries that just _won't die_, no matter how hard people have tried. My god, ImageMagick was written in 1987, and it now has Haskell bindings[0]! The only way to get that sort of longevity (and old code is good code, after all [1]) is to write in language that will outlast the ups and downs of the language or framework du jour, and C and C++ have proven to have that staying power." [0] http://hackage.haskell.org/package/imagemagick http://hackage.haskell.org/package/imagemagick [1] http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html
svalorzen 12y ago
I don't understand the point about the subset of C++. Nobody is really saying that, they are saying that for most things pointers should not be used, since they would not be needed. But when they are needed, they exist and should be used. If you need to create your own class which handles memory, (smart)pointers are the way to go. If you need to interface yourself with a C library, bare pointers are the way to go. The fact that most screws have cross or line head cuts does not mean that I won't ever buy a star-shaped screwdriver. When you don't need it, you don't need it. But when you need it, there's nothing else like it. On the other hand, higher level languages just cut on what you can do, and just give you a big ultra powerful hammer with which you can slam everything together. I guess it works, but I find it rather sloppy working.

by cbd1984 12y ago

72deluxe 12y ago

Thanks for the upvotes. You are right about both of these subsets pointing to other languages; I had not thought about that! I myself throw pointers around all over the place because I am restricted by my Windows compiler (no C++11 features) and I don't do stupid things with them (and am a slow learner for new features...). I suppose the performance gains are negligible in simple applications but in performance critical applications they can make a difference - games, web servers etc. See how Facebook built their PHP to C++ interpreter for reduction in running costs and heating costs. PHP was more convenient to write (and PHP developers are cheaper to hire I presume) but I wouldn't welcome all programs being of the "interpreted" type. With C++, the push for type safety and making the compiler do the work for you will mean more efficient programs and less run-time checks. This is particularly important on mobile devices where processing usage = less battery life. And I would be far happier running an application for a few extra hours on my laptop if it was written in a sensible language and made efficient use of my hardware; lots of little performance gains add up. Imagine the horror of apps being written entirely for developer convenience with little thought to performance - you could kiss goodbye to a big stack of power worldwide. That problem is only going to get worse, and the "there's processing power so I'll use it" approach is what gave us bloatware in the first place. So I suppose application and system program development is a tradeoff between developer convenience and user convenience (battery life, speed etc.)

pyrois 12y ago

Good point! For me, I think the question here isn't so much "performance gains" as "interoperability, near-ubiquity, and staying power". For "interoperability", I'm just going to quote myself: "If you write your library in Perl, guess what, only people writing Perl will use it. If you write it in Java, well, maybe the Scala folk will wrap it up, or the Jython folk, but you won't get any people writing in Ruby to use it. If you write it in C++, you can provide efficient bindings to any of those languages." In terms of ubiquity, what I mean is that almost every platform has a standards-compliant-ish C++ compiler for it. And before people get in a tizzy, I mean weird platforms, not just computers with a browser installed. That's Intel, yes, but also DSPs, FPGAs, ARMs, and whole host of other chips. This didn't used to be true, but with LLVM, almost an entire standards-compliant C++ toolchain can be generated for your platform pretty easily. The exception tends to be, ironically enough, exceptions. They need to be special-cased for your chip, but still, C++ exists in places where the JVM doesn't dare go. And finally, for staying power, I'll quote myself again! "Look at FFmpeg or ImageMagick. They are libraries that just _won't die_, no matter how hard people have tried. My god, ImageMagick was written in 1987, and it now has Haskell bindings[0]! The only way to get that sort of longevity (and old code is good code, after all [1]) is to write in language that will outlast the ups and downs of the language or framework du jour, and C and C++ have proven to have that staying power." [0] http://hackage.haskell.org/package/imagemagick http://hackage.haskell.org/package/imagemagick [1] http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html

svalorzen 12y ago

I don't understand the point about the subset of C++. Nobody is really saying that, they are saying that for most things pointers should not be used, since they would not be needed. But when they are needed, they exist and should be used. If you need to create your own class which handles memory, (smart)pointers are the way to go. If you need to interface yourself with a C library, bare pointers are the way to go. The fact that most screws have cross or line head cuts does not mean that I won't ever buy a star-shaped screwdriver. When you don't need it, you don't need it. But when you need it, there's nothing else like it. On the other hand, higher level languages just cut on what you can do, and just give you a big ultra powerful hammer with which you can slam everything together. I guess it works, but I find it rather sloppy working.