C++ and the STL 12 Years Later: What Do You Think Now? 435
profBill (98315) writes "Way back in 2002, Slashdot ran a story asking what people thought about C++ and the STL. Well, it's 2014 and C++11 is well out there with C++14 on its way.
I teach a second programming course in C++ with a heavy emphasis on the STL (containers and generic algorithms). I just wondered what people think about the situation today. Personally, I think C++11 has cleaned up a lot of problems, making it easier to use, but given all those who work with C++ for a living, I wondered what they thought today compared to then. Are people using C++11? Does it matter at all? I'd love to share the responses with my students! They are always curious about what practitioners are doing these days."
I teach a second programming course in C++ with a heavy emphasis on the STL (containers and generic algorithms). I just wondered what people think about the situation today. Personally, I think C++11 has cleaned up a lot of problems, making it easier to use, but given all those who work with C++ for a living, I wondered what they thought today compared to then. Are people using C++11? Does it matter at all? I'd love to share the responses with my students! They are always curious about what practitioners are doing these days."
Feels Dated (Score:5, Interesting)
This will probably come off as a troll, but it's really not intended to be. And keep in mind this is just my experience in my domain with the type of projects I've worked with. There's lots of different domains/projects sets where this wouldn't apply.
I used to love c++ and berade people who used wimp languages like Java. These days I mainly use java, and when I do have to use c++, it feels painfully dated.
At to C++11, while it added some useful stuff, in general it feels like it's just flailing while trying to bring in some of the language features of newer/more modern languages. The new concurrency stuff in particular is just plain unseemly.
Also, a relatively minor but annoying and long-standing problem with doing anything non-trivial in c++ is the lack of consistency between 3rd party libraries. Java has spoiled me into expecting everything to adhere to one convention, but with a c++ project as soon as you've got more than a few external libraries, you end up with a huge mess of code that doesn't mix properly, and writing adapters for everything to get that consistency is just insane.
Long rant short: I'm finding myself using c++ now mainly for:
- small bits of functionality to be used via JNI
- small stuff mainly focused around one library/task (Qt, pqxx, whatever)
Doing anything large and complex with c++ these days just doesn't appeal to me any more. I can build it much faster with java, it'll be more maintainable, and performance wise it's fine for what I do.
Also: floating bottom popup ads.. really dice? You just fell off one mans adblock whitelist.
Re:Simple (Score:2, Interesting)
Who can't nowadays? Embedded ARM SoCs come with GB's of RAM, and plenty of compute horsepower.
Unless you are bit twiddling on an AVR, or other micro, why not?
Re:Keeps getting better. (Score:5, Interesting)
I'll agree with C++11 in particular added a lot of stuff that I've been whining about for a long time. It's certainly moved forward and not backwards, and as you said, has managed not to rustle too many jimmies along the way.
That said, with improvements in hardware and languages like Java becoming way more practical, I just find it hard to justify using c++ for anything that doesn't absolutely need to be in c++, and JNI has made "so just write that one part in c++" a common option as well.
Not saying the useful space for c++ is gone, just that it's shrinking, and in the area I work, it's practically gone.
Not just dated... (Score:5, Interesting)
I've used it off and on since "c with classes", and while it's regularly improved at the detail level, it's still
- non-orthogonal
- complex
- exceedingly subtle in spots.
I think the best characterization is still Ozan's:
Re:Feels Dated (Score:5, Interesting)
Ruby makes sysadmins cry. I tried updating a legacy server yesterday that is running a ruby app. After two hours of trying to make it work, I gave up.
c++ has greatly improved, also thanks to STL (Score:5, Interesting)
The STL does one thing very well: it's very predictable performance-wise while being reasonably useable.
When you use it, you know perfectly what the performance is going to be.
It also offers some occasionally-useful features (std::weak_ptr for instance). c++11's move constructors and rvalue references are very good for squeezing out the last bit of performance where possible and for ensuring exception safety to certain operations; although it's mostly useful for very low-level, entrenched libraries such as the STL. Lambdas are syntactic sugar, but a well flavored one.
c++ is now a very different beast than it was in the 90s. If used properly, it can be very effective (performance-wise) in complex projects. But it can also give programmers tons of rope to hang themselves with.
Re:The build process is still shyte (?) (Score:2, Interesting)
The problem isn't the tools to build C++ it's the nature of C++. Things like Java, Python, (and I assume JS) are easy because they're built on the idea of importing modules where C/C++ is built on linking translation units.
Re:It's a turd that's slowly being polished (Score:4, Interesting)
D *is* neat.
The only problem is lack of momentum.
It was Bjarne himself who said that there are two kinds of programming languages: those everyone complains about, and those that nobody uses.
On-topic, lots of people are going to hate C++, for its multi-paradigm "everything and the kitchen sink" approach combined with near-C-compatibility and low-levelness. It's the kind of language where two programmers come up with five different ways to do the same thing, and four of them are probably wrong in non-obvious ways. It's fun though, in the way that a high-performance sports car is fun to drive, but easy to wipe out.
I've been using it professionally for 15 years now, and if I observe anything, it's that the longer I use it, the more my stuff looks like C. I keep shaking my head at younger colleagues mis-using templates all over the place ("re-usability!", and hour-long compile times, coupled with really non-obvious implicit conversions and instantiations, never mind the error messages), and object-oriented hierarchies where each object is such a tiny part of the system that you need to remember 10 classes at the same time just to have a slight inkling of what this thing is actually supposed to do.
I still have that nearly irresistible urge to defend the language whenever discussions like these come up, but so much of that is because it's the language I use all bloody day. And then I write something incredibly useful in 10 lines of Python.....
C++ has its place, a masochistic place, ostensibly programming a higher-level abstraction than the people writing plain C ("troglodytes!", but most of them actually seem to know what they are doing and rustle up the higher-level abstractions directly in C, I have respect for you guys), and the people who don't have that much need for low-level features, the last drops of performance or cross-platform compilation (you're probably working in Java, C#, Python, Ruby, and *enjoying it* most of the time. And yes, you Java guys have every right to tear into me about cross-platformness, it's not like it's just hand-waving in C++ either). It's sort of a similar niche to PHP I guess. You know full well that a lot of the reasons for the hate are true, but all you have is this swiss-army-knife of a hammer and everything must be a nail.
No C++11, little STL (Score:3, Interesting)
I work as a software engineer for a major software company. We do not use C++11, and likely won't start for years. Due to the existing code base, changing up tools is a costly and dangerous thing to do and it is never done unless absolutely necessary.
STL is something of an abomination. Good intentions, and we do use some of it, VERY sparingly, but generally speaking it makes code more difficult to understand and maintain.
Re:Feels Dated (Score:5, Interesting)
The Dev side of me loves Ruby. It's a nice language, it's powerful, the standard library is nicely complete and there are Gems for pretty much everything I could ever need.
The Ops side of me hates Ruby. Managing all those Gems on any given server is just horrible, rbenv & rvm need to die in a fire, there are a apparently one hundred different ways to run an application and proxy requests to it, and of courses Gems exist outside of the system package manager and that's always bad.
STL issues... (Score:5, Interesting)
From Page 3 of this [microsoft.com]:
The C++ STL, with its dyslexia-inducing syntax blizzard of colons and angle brackets, guarantees that if you try to declare any reasonable data structure, your first seven attempts will result
in compiler errors of Wagnerian fierceness:
Re:c++ has greatly improved, also thanks to STL (Score:2, Interesting)
The trouble with a language giving tons of rope to hang oneself is, on a team project, there will always be some coders who will in fact hang themselves, and in doing so hang the whole project. That's why C++ is OK for small/one-coder projects, but Java is the language of choice for big teams. Of course the whole project can also be hanged by the designers and architects...
Re:Feels Dated (Score:4, Interesting)
Funny, that's precisely how I feel when I have to use Java - "Where's capability X? Oh, dang, you don't have it. Wait, where's capability Y? Ugh, you don't have that either? Wait, I need to go through all this mess to do Z? Seriously?". Feels like pulling teeth.
I guess it's whatever you're used to.
I really love C++11. It's not perfect, mind you. The last standards-problem I ran into was that you can't template a class over a constant floating point value, only integer/boolean values... it was designed because a programmer might accidentally compile huge numbers of classes via template metaprogramming or the like when they only wanted one due to the imprecision of floating point values, but 1) how often are people seriously going to template metaprogram over a floating point value like that, and 2) who knows template metaprogramming but is unaware of the imprecision of floating point values?
That said, there's tons of great new stuff in the standard that I just love. Just to pick one: I love how the combination of lambdas and the new threading utilities makes it trivial to inline-thread any task, no matter how mundane. My favorite example is a single-line asynchronous packet handler (assuming you have a packet-handling factory class and a data read routine onhand) - repeatedly reads data, generates a smart pointer to a handler and runs it in its own thread, wherein it deletes itself when the thread expires. Okay, two lines if you want the code cleaner and you put the while loop on its own line, but still...
Re:Feels Dated (Score:4, Interesting)
Well, I'm totally developer, and I *don't* like Ruby. Partially because it's too slow, but mainly because it doesn't support utf-8 (or actually any unicode) well. That needs a gem. I really like Vala even though I find it unusable. (Poor documentation and incomprehensible error messages.) It seems to be aimed only at people who are already experienced in GObject programming...which is a weird target audience for that kind of language.
I *don't* like Java, though that's what I'm using at the moment. I prefer Python and D http://dlang.org/index.html [dlang.org] . But Python doesn't handle multi-processing well, and D is missing too many libraries. (Outside of the library problem, D is the best language I've encountered.)
My main gripe with C and C++ is the horrible way that they handle Unicode. And it's not as if they didn't have alternatives available before they even started to deal with it. (C has the argument of "maintaining simplicity" to justify shoving that off to a non-standard library, and glibc does a reasonable job. C++ doesn't have that argument.)
A secondary grip with C/C++ is poor multi-processing. This isn't quite fair, though, because I'd already decided that they were unusable due to the unicode handling issue. (I also don't like Java's choice of utf-16. I much prefer either utf-8 or utf-32. utf-16 seems to inherit the problems of both of the other choices.) Since I'd already decided that they weren't acceptable choices I didn't seriously look into their methods of multi-processing.
Note that for BOTH unicode handling and multi-processing I would prefer D over any other choice I've seen. But the lack of libraries counts as a heavy enough strike against it that I'm using Java..
FWIW, I suspect that both the Dev and the Op sides of you would like D. (Digital Mars D)
Re:Feels Dated (Score:3, Interesting)
Disclaimer: I'm a game developer with more than 15 years of programming experience in various fields, most of the efficiency-oriented, so my perspective is skewed towards that segment of the industry.
The instant I was exposed to C, it was love at first sight. The control, the zero-overhead philosophy, the power... It became my language of choice then and there, and C++ quickly followed. I don't understand all the bitching and moaning about C++ (as opposed to C,) because C is (almost) a proper subset of C++, and you just don't have to use what you don't know or like or are comfortable with. I've been using C++ for about 12-13 years now, along with many others, including Perl, Python, JavaScript, C#, Lua, etc., but I have never felt any of them were as expressive or as powerful as C++, or gave me the same level of control. Sure, each of these other languages is good for many tasks (mostly due to the domain-specific libraries/frameworks available for them,) but I've never been convinced that using any other language, I could accomplish more than half of what I do on a day to day basis with C++.
And C++11 was a fantastic step forward. I just naturally started using most of its new features, from auto and range-based loops to r-value references and moving to variadic templates and lambdas. I didn't use any of these just to have used them; it happened organically and naturally. And as a result, my code got more beautiful and more powerful and more efficient. Over the past few years, while compiler and library owners were in the process of implementing and adopting C++11, I've found myself using (or wishing for) still-unsupported features on many occasions, and going back to the old methods have always been a painful and jarring experience.
A non-issue for me is the complexity of the language. I think of myself as the kind of C++ programmer that knows about 90% of the language and can put that percentage to use. I may not be comfortable or proficient with all of that 90%; I certainly couldn't have written something like Boost.Lambda or Boost.Spirit from scratch, but I can read and understand (most of) them. The way I see it, the complexity is just the cost that comes with all that power. Could it have been simpler without any sacrifice? Most probably, but not significantly simpler. And it's not at all clear to me how you can accomplish that. All of us programmers have seen many many attempts at simplification, at "one size fits all", and none of them work.
And knowing all those complex and complicated stuff is totally worth it. I think I know 90% of C++ and I use all of that; with varying frequencies to be sure, but I do employ all I know in my everyday code. So, I pity the programmers that limit themselves in their knowledge of the tools at their disposal. I cannot understand how one can know "just enough" of a programming system; because every little bit you don't know will impact your code for the worse.
I grant you that the C++ space has other problems. Very serious one. But they are not fatal. IMHO, the most important problem C++ has today is incompatible libraries. How many libraries implement their own containers, strings, threads, I/O, timers, etc.? In an asynchronous context, how would you wait on two incompatible mutex objects from different libraries at the same time? How much of your process' time is spent converting strings or copying buffers between incompatible frameworks? This has come about because of the C++ standard library lacking many essential features, and because of bad implementations and compilers. But all of that is improving. The size of the standard library is growing with all the satellite working groups around the standardization committee. The compiler and standard library implementers are delivering and fixing new (standard) features faster than ever (influenced greatly by Clang and the new blood it brought to this sector.)
In short, C++ is great and it's getting better than ever, faster than ever.
Re:c++ has greatly improved, also thanks to STL (Score:4, Interesting)
Lambdas are syntactic sugar, but a well flavored one.
Lambda are the one feature that keeps me using C++. Once you grok functional programming, you'll never do with out. Writing whole functor classes is a huge amount of work, and error prone, for the type of things I need them for. There's a reason why old C++ code didn't make heavy use of them -- yet if you go into the world of functional programming, they are everywhere, and your code is much shorter and more predictable.
My old supervisor was convinced that a certain portion of people simply don't ever make the cognitive leap.