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.
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.
Reading through "Effective Modern C++," I was constantly thinking, "How is anybody supposed to remember all of these corner cases?"
Being mostly a C programmer, my code in C++ was basically (as he coined it) fancy-C. Then he rewrote my code in "the C++ way," after which the code became completely opaque to me.
My initial mistake was that I expected C++ to be like (or similar to) C, a mistake I believe many of us make. C++ is a lot more complex in scope (not necessarily in a bad way, either) and requires proper learning.
I came to the realisation that C and C++ are not even similar languages. Yes, you can write proper C code in C++ (with a bit of added strictness), but that's not how one should write C++. Also, I think that lot of the "anger" towards C++ is that the the names makes you think it's like C, but then you start learning the language and realise that in fact it is nothing like C on the outside, just on the inside.
Anyway, I'm not hating on C, I actually haven't taken on the quest to learn it properly, and I still rely mostly on C.
I have worked with people who write C++ in "fancy C" style too.
Cheers!
I feel it's even worse than that, though. There seems to be a culture among C++ programmers to do things in overly clever ways and to push the limits of readability and understandability. Just look at the headers for the standard C++ template library, for example. (I'm currently looking at the ones shipped with gcc.) They don't even use consistent indentation, and have single letter variables that are meaningless to all but those who wrote it. It's pretty frustrating to deal with.
On one side, very rigid companies barely using C++11, mostly as a better C with improved type checking.
On the other side, researchers making use of every template metaprogramming trick they can remember of.
These files are only intended to be seen by the compiler and it doesn't complain about indentation or single letter variables.
template<template<typename> typename X> struct D; // OK
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.
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
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.
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.
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).
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 breakageWhat 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.
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++.
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).
I should have added "and also high level". I did that now.
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.
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.
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?
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.
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 [1] http://www.joelonsoftware.com/articles/fog0000000069.html
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.)
I imagine you are in the lucky position to have full control over the whole code, right?
Back on my C++ days at work, 1999 - 2005, there was always a lucky guy having to track down pointer misuses across the project source code.
In other jobs I didn't have access to all the code but there were coding standards, regular reviews, and younger developers were mentored by older ones and their check-ins to repositories were vetted to ensure at least some standards. CPPCheck was also useful in some cases, and that Borland memory corruption tool that got built into the executable and caused false positives most of the time...
class HNUser
{
public:
HNUser() {
if (commentPraisesCorCPP()) Downvote();
}
};On the other hand, one of the most frequent problems with our Java services is "GC thrashing".
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.