11–20 of 93 posts
I've heard so much laid at C++ feet over the years, but I don't find it all that horrible to work with. It seems about on the same level as Python to get most things done, just without all the magic of the python standard library. Are there some good stories of the bad of C++ that anyone can share?
I feel like it's a bit grasping if you need such a complex example to debunk a straw man. Implicit garbage collection is about the ease of writing code, not reliability. You make the compiler work for you by not making what you want explicit. Yes, for bad programmers, this leads to better code, but that doesn't mean you don't benefit from implicit garbage collection if you are a good programmer.
C++ offers the most flexibility, and using containers and smart pointers makes code that doesn't care much about memory look quite decent too. I have to admit that Swift makes it a breeze though, you don't have as much overhead in thinking about memory management.
Here's a good myth: "Only program in C++ if you absolutely have no other option." I believe in this myth, I also am currently working on a project in C++ and reading one of Strousup's books. I think even Strousup shares this belief, but he would probably phrase it a bit differently. (My project is interfacing with the Unreal Engine by Epic that exposes a C++ API.) Just putting this out there for the discussion's sake…
I've been doing nothing but modern C++11 for a year solid and I have to also agree. C++11 and its standard libraries are a huge improvement but is still difficult to iterate and prototype with. Templates, lambdas, and generic programming are great additions but still very difficult to deal with and debug at times. By using Intel's compiler performance can really scream, but the time it takes to get things done is ver…
Choice of programming language is an architectural decision with a big impact and it can't come down just to preference or how nice a language feels, although that plays a part too. One can also do quick prototyping in one language and the real thing in another one, although prototypes have a nasty habit of surviving into production.
What comes to mind when you hear "reliable software"? Personally, I immediately think of critical embedded systems like rocket and spacecraft guidance and automotive control systems. And one thing I hear repeatedly is that many well-known coding standards for building such critical software prohibit all dynamic memory allocation, because dynamic allocation is a potential failure point.
And of course, if you don't have dynamic allocation, you don't need garbage collection, because it would have nothing to do. So if the software that needs reliability the most often doesn't use dynamic allocation, only the most ignorant could think that you need garbage collection for reliable software.
I've heard so much laid at C++ feet over the years, but I don't find it all that horrible to work with. It seems about on the same level as Python to get most things done, just without all the magic of the python standard library. Are there some good stories of the bad of C++ that anyone can share?
Though not updated for C++11, a place to start would be the C++ FQA [1]. [1] http://yosefk.com/c++fqa/defective.html
I feel like it's a bit grasping if you need such a complex example to debunk a straw man. Implicit garbage collection is about the ease of writing code, not reliability. You make the compiler work for you by not making what you want explicit. Yes, for bad programmers, this leads to better code, but that doesn't mean you don't benefit from implicit garbage collection if you are a good programmer.
My experience with GC on Android is that it's nice when it works, but when you have to optimize you're screwed. I'd rather have a system like in Swift where the destruction of objects is deterministic. deinit can take care of releasing resources in time. C++ offers the most flexibility, and using containers and smart pointers makes code that doesn't care much about memory look quite decent too. I have to admit that S…
I feel like it's a bit grasping if you need such a complex example to debunk a straw man. Implicit garbage collection is about the ease of writing code, not reliability. You make the compiler work for you by not making what you want explicit. Yes, for bad programmers, this leads to better code, but that doesn't mean you don't benefit from implicit garbage collection if you are a good programmer.
No, it is about reliability. You are confusing not always necessary/perfect/optimal with average case reliability. On average, automatic memory management has less bugs because certain classes of mistakes can be entirely eliminated.
Also this argument of good programmers don't have to rely on X as a crutch is more about pride than productivity. In the real world, most teams have code touched by developers at a variety of skill sets and everyone's contributions affect quality of code so tools should be measured across levels of expertise.
If you look at the highly cited research on garbage collectors I believe you'll find most of it concurs as to the benefits, edge cases not withstanding.
Here's a good myth: "Only program in C++ if you absolutely have no other option." I believe in this myth, I also am currently working on a project in C++ and reading one of Strousup's books. I think even Strousup shares this belief, but he would probably phrase it a bit differently. (My project is interfacing with the Unreal Engine by Epic that exposes a C++ API.) Just putting this out there for the discussion's sake…
I have been writing C++ for over a decade and am currently writing a cross-platform GUI for controlling remote hardware over a network link (multicast). With accelerated graphics for 3D interaction, entirely custom widgets/controls, and interworking with a low-level communication library that my colleague has written, other languages would have been awkward. There is reuse of parts of the library with the remote hardware I think, as that is written in C (isn't all embedded stuff?). The C++ nature of the library will also mean less pain when porting to other platforms.
Higher level languages may be more fashionable but who wants a slow GUI app written in Python and a big runtime to distribute with it? (How I detest all of RedHat's update programs over the last 15 years and Ubuntu's abysmally slow software centre....). I know people like to hate C++ because it's complex compared to BASIC/Pascal/Python/JavaScript/whatever is in fashion now but its flexibility allows construction of complex concepts.
I have also written servers and web servers in C++ and enjoy cross-platform use of them (albeit with some macro hash-defs for compilation); the clients for them are also native GUI apps written in C++. Admittedly many of the applications I have written could have been written in other languages but it's the way I think; the stability of the development platforms is a great attraction for me (contrast this with .NET 2.0/3.5/4.0/5.0 differences and the big runtimes that need to be thrown around everywhere).
I suppose it's the right tool for the job in the most part, and if you're just starting out with C++ then it may be more painful to get something usable and understand what's going on compared to writing a few lines in JavaScript and showing them in your web browser.
But I find it rewarding. Horses for courses I suppose.
I've heard so much laid at C++ feet over the years, but I don't find it all that horrible to work with. It seems about on the same level as Python to get most things done, just without all the magic of the python standard library. Are there some good stories of the bad of C++ that anyone can share?
Really, "For reliable software, you need Garbage Collection" is the straw man you're going to attack? What comes to mind when you hear "reliable software"? Personally, I immediately think of critical embedded systems like rocket and spacecraft guidance and automotive control systems. And one thing I hear repeatedly is that many well-known coding standards for building such critical software prohibit all dynamic memor…
If we're going to be thorough about a discussion of reliability in software, we have to include cost in the equation. Rocket and spacecraft systems have extremely high cost per SLOC. It stands to reason that there might be solutions for producing reliable software (for some standard of reliability) far more rapidly and cheaply than the folks at NASA.