4 ms·

Portability is still a good reason to use C++. If you want to be portable between Android and iOS, for example. C# on either platform requires you to ship an ex

Portability is still a good reason to use C++. If you want to be portable between Android and iOS, for example. C# on either platform requires you to ship an extra 10Mb of libraries, and (especially on older phones) adding C# overhead on top of everything else just doesn't make sense. I write games, mostly, so performance does matter to me, though I'm not trying to squeeze "every last bit of performance" out of a chip. I just want some parts of the code to be entirely predictable in performance. So C++ and OpenGL are still my tools of choice. Been using C++ for years and would ace that set of interview questions (except possibly the list of algorithms in <algorithms>). And yet...I actually hate C++. It just happens to do the job better than anything else. And it also happens to interface really well to a REALLY good scripting language, Lua. To some degree I wonder why everyone focuses so much on Java or C#, when the amount of overhead code you have to write is similar in both cases to C++. Yes the languages are easier to understand, which is good, and they're often wrapped in IDEs that make it easy enough a monkey can produce code that will compile, but it still requires a lot of boilerplate to do just about anything. More than C++ in some cases, though not always. So much that they make the IDEs write a lot of boilerplate for you -- but the overhead is not only in typing out the lines, but in screens and screens of code that distract you from the actual problem you're trying to solve, and that you have to sift through to find the code with the bug you're looking for. So I stick with C++ for things that need speed, and I use Lua for things that don't -- and I promise you that I can write just about anything in fewer (legible) lines of code in Lua than it would take to do the equivalent in C# or Java. And since # of bugs is proportional to the number of lines of code, I end up way ahead.

deleted 14y ago
[deleted]
seanmcdirmid 14y ago
> Portability is still a good reason to use C++. Quite true, thankfully WP8 supports native now. If portability is not a big deal, I prefer C# and DirectX (via sharpDX). It's much less code than C++, and just not as insane. > And since # of bugs is proportional to the number of lines of code, I end up way ahead. Can't tell if you are being serious here. That's just not true at all; it's well known that LOC is a poor indicator of bug occurrence.
- reinhardt 14y ago
  Not only LOC is a poor indicator of bug occurence but strictly speaking it's not even positively correlated. Some of the worst bugs are errors of omission, forgetting to handle special cases. Minimizing such cases is a noble goal leading to both less LOC and bugs but unfortunately the real world is riddled with them.
  - SomeCallMeTim 14y ago
    Missing the point. If I create an algorithm in X lines of code in one language, and I can create the same algorithm in another language in X/10 lines of code, it will be easier to understand the latter IF ONLY because it's more concise. And easier to understand means that, given a spec, it's easier to see that it's been implemented, special cases and all. And easier to understand also means the bugs will be more obvious, easier to prevent in the first place -- and easier to find and fix when they do occur. Q.E.D. If you want to see an example, check out this benchmark -- the Lua code [1] and the Java code [2], with Java at 9x the Lua. Can you seriously claim it would take the same amount of time to debug both, and that they have an equal opportunity for bugs? [1] http://shootout.alioth.debian.org/u32/program.php?test=knucleotide&lang=lua&id=2 http://shootout.alioth.debian.org/u32/program.php?test=knucl... [2] http://shootout.alioth.debian.org/u32/program.php?test=knucleotide&lang=java&id=1 http://shootout.alioth.debian.org/u32/program.php?test=knucl...
- rymith 14y ago
  That's interesting, I've read several papers on a direct positive correlation of LOC to # of bugs. Do you have any papers to back up that assertion that there is no correlation. Common sense would dictate that the more places humans can insert an error, the more errors will be inserted.
  - seanmcdirmid 14y ago
    Defect rate depends on a lot of things: the language, the programmer's experience and skill level, the kind of code being written. You have to normalize for those factors before you can even begin to think about correlating LOC to estimating bug counts. Now, take a language like Perl, Scala, or APL, where you can do a lot of things on one line of code; the bug density is obviously going to much higher than Java. Given C++'s lack of much safety (both static and dynamic), defect rates will also be higher there also. Then not all defects are created equal. Can the defect be easily detected via static analysis or unit testing? Those defects will wash out during the dev process, but the time needed to find and fix them has to be considered. We also have to apply more weight to wicked defects that are not easily detected (say memory corruption in C++ that causes bad behavior away from where the defect actually originates). I don't have any papers though I believe this style of thought originates from the 70s (like everything else in our field). There is always the folktale about Simoni: some PM at early MSFT instituted a lines of code metrics to measure and rate programmer productivity. The first week, Simoni wrote down something like -10000 LOC for the amount of code he deleted that week. The PM was pretty silent after that. I'm sure I've got this story completely wrong, but the point is that LOC are a crude and crappy metric in any case.
thesz 14y ago
Or, you write edsl in any language a little higher than C.* and you get portability and platform and domain specific optimizations.
- CJefferson 14y ago
  Really? Serious question, what can I write an edsl in to get reasonable performance, and be able to run the resulting code on iOS, Android, Windows and Mac?
  - shawn-butler 14y ago
    I suppose I would consider NME[0] pretty much to be a domain-specific language where the domain is ActionScript. And that domain covers a pretty hefty majority of application use cases. And you can use NME to create compelling (performant) applications on those platforms you have listed and more. Recent builds have included support for qnx/bb10 and I think they are working diligently towards win8. Since the underlying enabling technology is haxe[1] you can use macros[2] to create more abstract DSLs specific to your use. Someone created a shader language for incorporating vertex and fragment shading into your code for example[3]. [0]: http://www.haxenme.org/documentation/about/ http://www.haxenme.org/documentation/about/ [1]: http://haxe.org/doc/features http://haxe.org/doc/features [2]: http://haxe.org/manual/macros http://haxe.org/manual/macros [3]: http://haxe.org/manual/hxsl http://haxe.org/manual/hxsl
EvilTengil 14y ago
I did not understand the author's opinion that C++ was no longer needed for writing portable code. When I look back on my previous projects, most of them have been written in C++ because that was the only feasible way of doing it I could come up with. For example how could I have done anything of this in another language like C#/Java? - Writing a Video on Demand streaming library that was using the torrent protocol and unicast sockets. Required to be platform independent. - Writing a web browser plugin for all webkit browser and IE that interfaced with OpenNI and Kinect SDK, using ffmpeg to stream RGBD video to a server. The plugin was based on Firebreath which is a C++ library for making portable plugins. - Developing a high-performance iOS/Android app which requires a lot of OpenGL graphics and computer vision algorithms. I don't particularly like C++, but I don't see how anything of this could have been done with another language. If so, please educate me!
shawn-butler 14y ago
With any interpreter or vm you have to factor in the LOC of that technology, so I think your measure is not accurate for calculating the statistical likelihood of defects. Also there is the significant added complexity in things like a JIT and bugs by side-effect, (e.g. the runtime hit by garbage collection sweeps). Admittedly for Lua the increase in size is not so big, what is the compiled interpreted now, like 200kb? In any case, it is certainly longer than the comparable C++ program. I agree with you completely that a more significant factor to correctness is in the "legibility" of the code to the author/maintainer. If you can read Lua better than you can read C++, one should by all means use Lua whenever possible because you will produce fewer defects. I think your point about why the industry focuses on java/c# when it requires the same overhead in code to c++ is exactly why there is a recent "resurgence" in c++ . The whole back to native is a recognition that java (especially j2me) and c#/.NET has failed to deliver on most of its marketing promises. It isn't to say they don't have compelling visions, but in the end they don't offer any more than C++ and you get alot more portability and predictability. Just my $0.02.
- wbl 14y ago
  Bug count is not a static per line of code measure. It also matters how well written and tested that code is. And when it comes to interpreters, they are very easy to test well. A JIT is perhaps more worrisome. But if those work, you can eliminate classes of bugs from what runs on top.
zurn 14y ago
> Portability is still a good reason to use C++. If you want to be portable between Android and iOS, for example. > C# on either platform requires you to ship an extra 10Mb of libraries, and (especially on older phones) adding C# overhead on top of everything else just doesn't make sense. These sound like two different problems. I think C++ is much less portable than C# but you might be right about the code bloat problem. Though C++ apps also quickly pick up bloat. Are you saying there is a common set of C++ libraries that ship with both iOS and Android that you could dynamically link to in your app portably? Or are you saying that you can get by with shipping less library code on C++ because there isn't a single big interlinked standard library?
- SomeCallMeTim 14y ago
  >Are you saying there is a common set of C++ libraries that ship with both iOS and Android that you could dynamically link to in your app portably? I do link in some of my own libraries, but the code compiles to less than 1Mb. Mostly what I link to is OpenGL, which is available on iOS and Android, and a few standard Posix APIs.

deleted 14y ago

[deleted]

seanmcdirmid 14y ago

> Portability is still a good reason to use C++. Quite true, thankfully WP8 supports native now. If portability is not a big deal, I prefer C# and DirectX (via sharpDX). It's much less code than C++, and just not as insane. > And since # of bugs is proportional to the number of lines of code, I end up way ahead. Can't tell if you are being serious here. That's just not true at all; it's well known that LOC is a poor indicator of bug occurrence.

reinhardt 14y ago
Not only LOC is a poor indicator of bug occurence but strictly speaking it's not even positively correlated. Some of the worst bugs are errors of omission, forgetting to handle special cases. Minimizing such cases is a noble goal leading to both less LOC and bugs but unfortunately the real world is riddled with them.
- SomeCallMeTim 14y ago
  Missing the point. If I create an algorithm in X lines of code in one language, and I can create the same algorithm in another language in X/10 lines of code, it will be easier to understand the latter IF ONLY because it's more concise. And easier to understand means that, given a spec, it's easier to see that it's been implemented, special cases and all. And easier to understand also means the bugs will be more obvious, easier to prevent in the first place -- and easier to find and fix when they do occur. Q.E.D. If you want to see an example, check out this benchmark -- the Lua code [1] and the Java code [2], with Java at 9x the Lua. Can you seriously claim it would take the same amount of time to debug both, and that they have an equal opportunity for bugs? [1] http://shootout.alioth.debian.org/u32/program.php?test=knucleotide&lang=lua&id=2 http://shootout.alioth.debian.org/u32/program.php?test=knucl... [2] http://shootout.alioth.debian.org/u32/program.php?test=knucleotide&lang=java&id=1 http://shootout.alioth.debian.org/u32/program.php?test=knucl...
rymith 14y ago
That's interesting, I've read several papers on a direct positive correlation of LOC to # of bugs. Do you have any papers to back up that assertion that there is no correlation. Common sense would dictate that the more places humans can insert an error, the more errors will be inserted.
- seanmcdirmid 14y ago
  Defect rate depends on a lot of things: the language, the programmer's experience and skill level, the kind of code being written. You have to normalize for those factors before you can even begin to think about correlating LOC to estimating bug counts. Now, take a language like Perl, Scala, or APL, where you can do a lot of things on one line of code; the bug density is obviously going to much higher than Java. Given C++'s lack of much safety (both static and dynamic), defect rates will also be higher there also. Then not all defects are created equal. Can the defect be easily detected via static analysis or unit testing? Those defects will wash out during the dev process, but the time needed to find and fix them has to be considered. We also have to apply more weight to wicked defects that are not easily detected (say memory corruption in C++ that causes bad behavior away from where the defect actually originates). I don't have any papers though I believe this style of thought originates from the 70s (like everything else in our field). There is always the folktale about Simoni: some PM at early MSFT instituted a lines of code metrics to measure and rate programmer productivity. The first week, Simoni wrote down something like -10000 LOC for the amount of code he deleted that week. The PM was pretty silent after that. I'm sure I've got this story completely wrong, but the point is that LOC are a crude and crappy metric in any case.

thesz 14y ago

Or, you write edsl in any language a little higher than C.* and you get portability and platform and domain specific optimizations.

CJefferson 14y ago
Really? Serious question, what can I write an edsl in to get reasonable performance, and be able to run the resulting code on iOS, Android, Windows and Mac?
- shawn-butler 14y ago
  I suppose I would consider NME[0] pretty much to be a domain-specific language where the domain is ActionScript. And that domain covers a pretty hefty majority of application use cases. And you can use NME to create compelling (performant) applications on those platforms you have listed and more. Recent builds have included support for qnx/bb10 and I think they are working diligently towards win8. Since the underlying enabling technology is haxe[1] you can use macros[2] to create more abstract DSLs specific to your use. Someone created a shader language for incorporating vertex and fragment shading into your code for example[3]. [0]: http://www.haxenme.org/documentation/about/ http://www.haxenme.org/documentation/about/ [1]: http://haxe.org/doc/features http://haxe.org/doc/features [2]: http://haxe.org/manual/macros http://haxe.org/manual/macros [3]: http://haxe.org/manual/hxsl http://haxe.org/manual/hxsl

EvilTengil 14y ago

I did not understand the author's opinion that C++ was no longer needed for writing portable code. When I look back on my previous projects, most of them have been written in C++ because that was the only feasible way of doing it I could come up with. For example how could I have done anything of this in another language like C#/Java? - Writing a Video on Demand streaming library that was using the torrent protocol and unicast sockets. Required to be platform independent. - Writing a web browser plugin for all webkit browser and IE that interfaced with OpenNI and Kinect SDK, using ffmpeg to stream RGBD video to a server. The plugin was based on Firebreath which is a C++ library for making portable plugins. - Developing a high-performance iOS/Android app which requires a lot of OpenGL graphics and computer vision algorithms. I don't particularly like C++, but I don't see how anything of this could have been done with another language. If so, please educate me!

shawn-butler 14y ago

With any interpreter or vm you have to factor in the LOC of that technology, so I think your measure is not accurate for calculating the statistical likelihood of defects. Also there is the significant added complexity in things like a JIT and bugs by side-effect, (e.g. the runtime hit by garbage collection sweeps). Admittedly for Lua the increase in size is not so big, what is the compiled interpreted now, like 200kb? In any case, it is certainly longer than the comparable C++ program. I agree with you completely that a more significant factor to correctness is in the "legibility" of the code to the author/maintainer. If you can read Lua better than you can read C++, one should by all means use Lua whenever possible because you will produce fewer defects. I think your point about why the industry focuses on java/c# when it requires the same overhead in code to c++ is exactly why there is a recent "resurgence" in c++ . The whole back to native is a recognition that java (especially j2me) and c#/.NET has failed to deliver on most of its marketing promises. It isn't to say they don't have compelling visions, but in the end they don't offer any more than C++ and you get alot more portability and predictability. Just my $0.02.

wbl 14y ago
Bug count is not a static per line of code measure. It also matters how well written and tested that code is. And when it comes to interpreters, they are very easy to test well. A JIT is perhaps more worrisome. But if those work, you can eliminate classes of bugs from what runs on top.

zurn 14y ago

> Portability is still a good reason to use C++. If you want to be portable between Android and iOS, for example. > C# on either platform requires you to ship an extra 10Mb of libraries, and (especially on older phones) adding C# overhead on top of everything else just doesn't make sense. These sound like two different problems. I think C++ is much less portable than C# but you might be right about the code bloat problem. Though C++ apps also quickly pick up bloat. Are you saying there is a common set of C++ libraries that ship with both iOS and Android that you could dynamically link to in your app portably? Or are you saying that you can get by with shipping less library code on C++ because there isn't a single big interlinked standard library?

SomeCallMeTim 14y ago
>Are you saying there is a common set of C++ libraries that ship with both iOS and Android that you could dynamically link to in your app portably? I do link in some of my own libraries, but the code compiles to less than 1Mb. Mostly what I link to is OpenGL, which is available on iOS and Android, and a few standard Posix APIs.