5 ms·
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++
by tinco 12y ago
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, perhaps someone could engage on it. I recently discovered to my horror that Apache Mesos is written in C++. They use the nice futuristic style Strousup would probably applaud though, still I think any other practical programming language would have been a better fit since it's just a sysadmin tool. Obviously they disagree.
- pyrois 12y agoDepends on how strongly you mean "no other option". For example, is Rust another option? I'm not sure how comfortable I am writing for a language with a version of "0.12.0". My understanding is that they make breaking changes fairly frequently (at least compared to the religious mania that is C++'s approach to backwards-compatibility). D seems like an option. Go, maybe, depending on what you're doing. Here's my standard example for when I would happily choose C++: I am writing an image processing library that I want to be able to run on both the PC and embedded platforms (e.g. one of TI's DSPs). I also want to be able to write low-cost bindings in python, ruby, etc. There are other options, but I think C++ is the best one in this case.
- Dewie 12y ago> Depends on how strongly you mean "no other option". For example, is Rust another option? What I tend to think people mean when they say that, is that you have some cycles to "waste" on a simpler - while also being high level - language. > Here's my standard example for when I would happily choose C++: I think the standard examples are certain application-level programs.
- k__ 12y ago> What I tend to think people mean when they say that, is that you have some cycles to "waste" on a simpler language. Isn't C simpler than C++ and doesn't waste cycles? The only "no other option" scenario I could imagine is, legacy code in C++ or using a framework that needs C++.
- Dewie 12y ago> Isn't C simpler than C++ and doesn't waste cycles? I should have added "and also high level". I did that now.
- maxlybbert 12y ago> Isn't C simpler than C++ and doesn't waste cycles? I gave a couple of C++ books to a recent CS graduate. She assured me that C++ would be easy to pick up because it has a much smaller standard library than Java. I smiled but didn't say any anything. Yes, C is simpler than C++. But that simplicity comes with a cost, mainly that the programmer has to keep track of more details. And the C standard library is smaller than the C++ standard library (and that would be true even if the C++ standard library didn't include the C standard library).
- cbd1984 12y agoAnother thing to think about: Program in C++ if you have memory to waste on leaks, or time to waste on plugging leaks. GC induces things that are arguably leaks, but in the average case they're controlled; leaks in C++ grow without bound in the average case.
- 72deluxe 12y agoThis leaks argument is really getting old. I have no leaks in my code. C++11's addition of move semantics and using references everywhere makes pointers unnecessary for the most part. You can use STL containers for putting your items into so shouldn't see raw "new" or "delete" operations in your own code very much; this is particularly true where you define your own move operators and move constructors. Even "old" C++ should have no leaks if you use RAII properly, have clearly defined container classes, use references everywhere or const pointers if you must. If you write sloppy code, you get sloppy output. See Stroustrup's "The C++ Programming Language Fourth Edition" (the blue book) section 3.3.3 Resource Management and 3.2.1.2 "A Container", where in this early part of the book Stroustrup explicitly directs to 'avoid "naked" new and delete operations" and to "use resource handles and RAII to manage resources". EDIT: Wahay getting downvoted - thanks! In any other language (eg. PHP) if there was a vocal crowd complaining about how their scripts are slow when they do something stupid like fetching an entire database table and then doing filtering within the PHP script itself, everyone would say "But you're doing something stupid - it is going to be slow" and nobody would argue with it. With C++, when you point out that someone is doing something foolish, you get downvoted and people start making arguments about features of the language instead to detract from the truth that you've highlighted, ie "but a good language wouldn't let you do dangerous things", which is the same as saying "knives can cut you - ban all knives!!". It's really wearisome, and always rears its head here on HN where C++ is NOT the language of the day.
- CyberDildonics 12y agoRust is likely not an option for most people using C++ yet. C++ has one huge advantage over almost every other language: its tools and eco system. MSVC++, Intel's ICC, GCC and LDC are all solid compilers where you will not paint yourself into a corner because of your tools. D is more mature but still can't compete on tools since only a few languages can make that claim. Your case is another big point. C++ can manage memory without raw pointers AND without garbage collection. It should be able to compile without a big runtime, but for some reason its modern dependencies are just as big as scripting languages.
- 72deluxe 12y ago"for some reason its modern dependencies are just as big as scripting languages" In what way? Isn't writing an application trivial with the STL? Even something like a GUI is possible with a small system and FLTK (although it isn't really very pretty).
- steveklabnik 12y ago> My understanding is that they make breaking changes fairly frequently http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html * now -> Jan 9: TONS of breaking changes * Jan 9 -> Feb 16: probably shouldn't break, but we reserve the right to deal with exceptional circumstances * Feb 16 -> six weeks, maybe 12: no more breakage
- CyberDildonics 12y agoI'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 very tough to deal with. Contrasting this to Julia/lighttable/Juno is like night and day. Programming in a canvas/all REPL style is unbelievably freeing since each little piece can be tested and iterated on quickly and easily. Then the program can be organized in a continuous matter while it is being made. The mental energy needed at any one point in time is massively decreased since classes, inheritance, types, memory, and data flow don't all have to be dealt with in an interwoven manner like C++. The performance won't be equal immediately, but being able to prototype, then optimize, then only have to replace minimal parts with native code after they have been shown to be bottlenecks is amazing (and calling C is even super direct because of strong typing) So after a solid year, I agree with the idea of using C++ only if there is no other option.
- blub 12y agoWell, you have to think in each case what makes sense to you, look at the requirements of the project, team skills, candidates pool, etc and pick the best fit. 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.
- CyberDildonics 12y agoJulia is one example of an alternative, but the real point of course is that even modern C++ requires a lot of extra mental energy that just isn't needed in almost any other language. It has its strengths, but I do agree with not using it unless it is completely necessary. Because of its massive language and compiler complexity it is becoming something of a black art the way assembly language has been in the past. Very powerful but very complicated.
- 72deluxe 12y agoI don't believe this myth. 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.
- cpitman 12y agoYes, I completely agree. I had a client that pushed for a large enterprise application to be written in C++. By large, I mean it took a ~30 person team about 3 years to develop. In the end, I think the 80/20 rule applied and well under 20% of the code was performance critical while the rest was handling common operations that in higher level languages would either be easy or part of a standard library. On top of that, once the client wanted to take over the project they had a hell of a time finding competent C++ developers. Back in 2005 two Microsoft developers (Raymond Chen and Mariani) did a blog series where one of them wrote and optimized a C++ Chinese/English dictionary and the other did the same in C#[0]. The naïve C# version outperformed the C++ version until Raymond performed several significant optimizations. [0]: http://blogs.msdn.com/b/ricom/archive/2005/05/10/416151.aspx http://blogs.msdn.com/b/ricom/archive/2005/05/10/416151.aspx
- leetNightshade 12y agoYou have another option: Unreal Engine Blueprints. If you're not comfortable with C++, use Blueprint, that's what it's there for.