Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

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."
This discussion has been archived. No new comments can be posted.

C++ and the STL 12 Years Later: What Do You Think Now?

Comments Filter:
  • Feels Dated (Score:5, Interesting)

    by Anonymous Coward on Wednesday April 30, 2014 @10:11AM (#46878337)

    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.

    • Absolutely agree - but in my case my preferred poison is Ruby rather than Java. I am using it on embedded systems because these days, it is fast enough on a modern embedded controller of the RPi variety.

      • Re:Feels Dated (Score:5, Interesting)

        by JustShootMe ( 122551 ) <> on Wednesday April 30, 2014 @10:36AM (#46878719) Homepage Journal

        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.

        • Re:Feels Dated (Score:5, Interesting)

          by Vanders ( 110092 ) on Wednesday April 30, 2014 @11:33AM (#46879675) Homepage
          I'm one of these irritating DevOps types.

          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.
          • Re:Feels Dated (Score:4, Interesting)

            by HiThere ( 15173 ) <<charleshixsn> <at> <>> on Wednesday April 30, 2014 @03:34PM (#46882985)

            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 [] . 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)

      • by epyT-R ( 613989 )

        ruby? on an 'embedded' platform? Your customers must not mind paying for 50x the hardware that's actually needed.

    • Not just dated... (Score:5, Interesting)

      by davecb ( 6526 ) <> on Wednesday April 30, 2014 @10:24AM (#46878547) Homepage Journal

      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:

      Everyone knows 40% of C++. Unfortunately, it's never the same 40%.

      • These are the three points I expect people to realistically bring against Perl. These three are definitely true of Perl as well. Inevitably what most people actually cite are memes about line noise, write-only code, and the impossibility of writing large projects.

        Orthogonality has its merits, but true 100% orthogonality is really rare in a language. Sometimes it's convenient to have a second way to do something, even if it's confusing to have ten ways to do it. Even assembly languages are seldom completely

      • Agreed (Score:4, Insightful)

        by Viol8 ( 599362 ) on Wednesday April 30, 2014 @10:58AM (#46879097) Homepage

        They added far too many features to the language in order to please everyone. Why? People who need high level languages have plenty of others to choose from.

        Personally I got sick of it and its never ending increase in complexity and just stick with a sort of C with classes and the occasional use of the STL and thats it. In fact sometimes I'll just use plain C. If I need a language with really high level constructs then thats what Python was invented for.

        • They added far too many features to the language in order to please everyone. Why?

          Languages grow over time and change as the world changes. What was adequate in 1980 is not in 2014. Nonetheless, I can't think of a single feature that C++ could do without.

          People who need high level languages have plenty of others to choose from.

          Such as? There are very few languages out there that have the combination of expressiveness, speed and stability of C+

          Personally I got sick of it and its never ending increase in comp

    • Re:Feels Dated (Score:4, Interesting)

      by Rei ( 128717 ) on Wednesday April 30, 2014 @12:14PM (#46880211) Homepage

      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: (Score:3, Interesting)

      by Anonymous Coward

      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

    • by epyT-R ( 613989 )

      So what exactly is dated about it?

    • The one thing I notice is that C++ greatly changed with STL. Much of the community moved away from using C++ as an object oriented language and instead use it as a generics oriented one. Even without using STL, templates have become vastly more common to use, and the templates being used are much larger. It feels odd because many of those collection libraries that were in use before STL were actually more efficient in many ways. Today C++ programs are bloated and they don't need to be. It's no longer t

  • by Anonymous Coward on Wednesday April 30, 2014 @10:11AM (#46878339)
    Totally biased, non-specific: Having written more than 1M lines of C++ in the late 80's early 90's, back when I'd have killed for an STL, I think every iteration adds real improvements without generating divisions amongst professional developers (unlike iterations of Java).
    • by Anrego ( 830717 ) * on Wednesday April 30, 2014 @10:16AM (#46878409)

      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.

    • Over the course of 10 years that would be about 270 lines a day 7 days a week, 52 weeks a year. Including debugging an testing? I don't think so my friend.

  • I haven't worked with C++ much for about 3 years, but when I did, manually editing Makefiles and the like caused more than a little indigestion. After having worked with Python, JavaScript with Grunt, several IDEs, and even crap like Maven for Java/Scala projects, I don't want to go back to the early steps of getting C++ projects just to execute. There seems to be no doubt that I've missed some developments in that area in the last few years, though.

    • Has anyone tried gradle [] for c++? It works well for java (less XML than maven, yay), but I haven't tried a lot of other languages.
    • Re: (Score:2, Interesting)

      by Anonymous Coward

      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.

    • by robmv ( 855035 )

      When I was trying to learn a more system level languages from higher level ones like Smalltalk, I found Makefiles to be archaic. I was delighted when IBM introduced what they called Configuration files on VisualAge C++ (PDF) [] (see Chapter3. An introduction to configuration files). It was easy to manage and the integration with the IDE was great [] (one of the first C++ IDEs I really liked). But the configuration files were hated by the people used to the Makefiles, it wasn't well received. As an newbie at that

  • by kinkie ( 15482 ) on Wednesday April 30, 2014 @10:41AM (#46878795) Homepage

    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.

    • by microbox ( 704317 ) on Wednesday April 30, 2014 @06:26PM (#46884741)

      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.

  • Back in the day I did a lot of c++, but nowadays I prefer things like c# (partly because I don't have to deal with header files any more). But I still keep tabs on C++ through reading questions on stack overflow. And what really amazes me is the number of "language lawyer" questions arguing over the precise definition of some point in a C++ standard - and that scares me into believing that no sane person could ever write well formed c++.

  • We use C++ exclusively for academic projects but we rarely use STL for performance reason. Some of the C++11 functions really come to rescue like number to string conversion, time keeping etc that may save a day but in general we use "templates" almost everywhere but use of STL is limited to some once in a while operations like loading data from an input file.
    • by Yosho ( 135835 )

      Out of curiosity, what are you doing that is so performance intensive that you can't use the STL? Have you done profiling on STL vs. custom containers to compare how efficient they are?

      • I wrote a project that was parsing text files that were several hundred megs in size, containing large numbers of floating point numbers in text in a reasonably complex structure. This all needed to be parsed and converted into simple data structures for processing. The initial version using STL streams for parsing and text manipulation was about 500 times slower than crawling bytes with switch statements and using standard C number parsing functions. 500.
    • Can you point to an example of how your container is more performant than the STL?

  • The C++ standard library is probably the highest quality standard library of any language I've seen.

    It is documented down to an very low level. I can't count the number of time I've been using some .NET library only to find out that it has some undocumented requirement, quirk, or wildly unexpected time complexity. You never get things like that in the C++ standard library -- assuming you've read the documentation thoroughly, you should never be surprised.

    The standard library takes full advantage of the language, and it's as lean as ever with the "don't pay for what you don't use" mantra generally remaining in full effect.

    A downside? I may be able to develop something that uses a tenth the RAM and half the CPU in C++, but despite the strengths mentioned above, it's going to take me at least twice as long and I'm going to need to juggle a number of inconsistent 3rd party libraries -- no doubt some of them being plain C so I'll need to make some RAII wrappers, etc. -- it remains incredibly low-level.

    Boost picks up some of the slack, but C++ really needs more of the things commonly used today. Things like HTTP, XML, web services, SQL, configuration, and cryptography should be built in, but they're only just now looking at a simple sockets library. This is a huge weakness. C++ is used in a lot of low-level situations so I don't know if these should be part of the standard library proper, but at the minimum an additional "framework" standard that implements high-level stuff for the more common unconstrained users would be immensely useful.

    The language itself is very strong, and C++14 cements even more useful things into it. The only things I wish they'd add is LINQ and async functionality similar to C#.

  • I think it's great (Score:5, Insightful)

    by Stele ( 9443 ) on Wednesday April 30, 2014 @11:00AM (#46879135) Homepage

    Unlike a lot of commenters here, I actually use C++ every day, and have been for about 20 years. I think the evolution of the language has been great.

    I write software for the digital visual effects industry, and it has to be fast, portable, and adaptable. To that end I tend to write as light-weight low-level code as possible, strongly separated from the UI, since I never know where I may end up needing to use it. For instance, when we decided to put a bunch of our filters on iOS, it pretty much worked as-is.

    One key to writing nice clean portable code is to avoid dragging in too many dependencies. At the lowest level, about the only external dependencies I used are a few things from boost. But with C++11, a lot of that functionality has moved into the core language (or the standard library). Threading and synchronization primitives such as atomic_int, thread, and mutex are now part of the language, and no longer need to be brought in from boost. This makes everything much cleaner, especially with build/test integration.

    lambdas are another thing I really like. Instead of writing messy functors (for auto-threading image processing kernels for example) I can drop the code in-line using a lambda. Much more readable and cuts down on complexity.

    The new move-semantics have also made nice improvements to code design and performance, allowing you to move whole objects around with practically zero cost as if they were references.

    On the UI side of things I usually use Qt, and there have been C++11-related improvements there as well, such as signals and slots now being type-safe.

  • Franken-monster (Score:5, Insightful)

    by countach ( 534280 ) on Wednesday April 30, 2014 @11:05AM (#46879225)

    Languages that aren't designed top to bottom at the beginning tend to evolve into Frankensteins. Perl, C++ have evolved in accordance with fantastically clever ideas, but end up being more complex than anyone wants to deal with, and a mess of syntax. Java is heading that way too. The question is can anyone put all this cleverness into something simple? Say what you want about things like lisp and scheme, they managed to put incredibly powerful ideas into something that is at its core simple. If only other language designers achieved it too.

  • The reusability and modularity of C and C++ has always been poor, and, though improved, still is. C is good for making your own linked list functions, not so good for using libraries containing those functions. We've persevered in spite of that, and created hundreds of libraries in C. But it's still a mess.

    The STL is fine as far as it goes, but, for example, it simply cannot integrate something like Perl's hashing abilities and regular expressions as well as Perl itself. The programmer can sort of approach the cleanliness of the Perl syntax by making clever use of C++'s operator overloading, but among the problems with that is that there are a small number of operators available for overloading. The programmer cannot create new operators. Better to retreat to the messy function call syntax. That is, instead of something like c=a+b; it's c=add(a,b);

    And the function call syntax has its own limitations. Unless the coders include the library for variable numbers of parameters (printf being the go to example of such a function), they're stuck with fixed numbers of parameters. Having to do prototyping is another annoyance. Surely computers have progressed to the point that it is not a huge imposition to ask a compiler to make 2 passes through the source code, or store the data types of the parameters of a call to an as yet unknown function, to resolve forward references itself instead of burdening the programmers with that chore? But even if those 2 limitations are addressed, calls are still like having to do math with prefix notation and still be forced to use parentheses everywhere even when the number of parameters are fixed, rather than a choice of prefix, infix, or postfix notation with some operator precedence so that it isn't necessary to surround absolutely everything with parentheses. In that respect, C is no advance at all over Lots of Irritating Superfluous Parentheses.

    Another resuability problem was name collision between different libraries. Two libraries with a "sort" function, for instance. To deal with this, it became the custom to prepend the library name to every function name. Now we have namespaces.

  • by Chatsubo ( 807023 ) on Wednesday April 30, 2014 @11:10AM (#46879311)

    In production software you don't always have the luxury of being able to switch to the latest and greatest in an instant.

    In the case of C++(and others) as things change you have to update compilers, this often(read: always) means stricter requirements as the compilers improve (IOW: Newer compilers catch potential problems in your code better than older ones, and moan about it more). When you have a system of millions of lines of C++, this means you have to dedicate manpower (which you probably need somewhere else) to fixing all these "new" issues before you can upgrade all your compilers. This is good, but you can't always dedicate 100% of your time to it. Aside: For our stuff we turn warnings-as-errors on always, which maybe makes this task more difficult than it is for others, but we get to catch bad code a lot quicker.

    My team only recently got to the point where all our stuff was in a state that we could start using the newer compilers and hence, standard. But we've been chomping at the bit to use C++11 for a long time. So yes, I do care. And yes, I think it's much better now.

    Why do we care?
    For one, lambda's make our lives, and code readability, SO much better. Especially when using the std algorithms.
    We will definitely be utilising variadic templates in our shop as we tend to be template meta-programming heavy. We avoid re-work like a plague.
    Personally I'm glad to see the new initialiser lists because we also stress TDD and nothing sucks more than not being able to set up test data easily and have it be readable. Almost always requires some instrumentation first.

  • The few experiments I've tried with STL have been a bit too heavy and slow - at least with my uses which are frequently not single threaded.
    My last test ran faster in python.

    so I'll stick with C. Good old efficient, manageable and predictable C.

    However I hear the STL is great for many people.
  • I have been working with C++ (as well as Java, C# and other languages) for several projects over the past 13 years. Since C++ is still the main language for the projects I'm paid to work on, I find the improvements to the STL useful every day in avoiding doing custom things. We used to have our own class similar to std::shared_ptr and std::unique_ptr, which we have since replaced with the standard. With std::bind() we have reduced the complexity of many of our functions. As another commenter said, the lambd

  • by mrthoughtful ( 466814 ) on Wednesday April 30, 2014 @11:23AM (#46879553) Journal

    We just migrated our codebase from C++ STL to C++11 and in general, it was worth the pain.
    The main benefits for us were better awareness of modern character encoding - but stuff like lamda functions are pretty cool too, and we could probably tidy up a lot of our earlier code to use more C++11 features.

    I was brought up on Assembler (Z80, 680x0) and moved to 'C', and then migrated to 'C++', so my early C++ was very C-like (not unusual). However, I've not looked back. I know that you are asking about C++11, but C++ itself is probably worth highlighting.

    I also know Java, Obj-C, (and a bunch of other languages that I have used in less commercially sensitive contexts) and there's a lot to be said for them too. But when I feel like getting close to the metal, it's C++ for me. I guess it's b/c one can still (just about) follow the assembler generated by it.

    But then I'm old in my approach. Modern optimising compilers, with coding strategies, static analysis (as well as excellent IDEs) probably have more effect on my productivity than any language sub-variant.

  • by EmperorOfCanada ( 1332175 ) on Wednesday April 30, 2014 @11:24AM (#46879555)
    I love templates when used in things like vectors, maps, sets, etc. Then combined with the new for loop iteration in C++11 it is great.

    But the nightmare is that many people are putting templates into everything so as to accommodate "future" flexibility. But the simple reality is that unless you are programming a hard core library it is a disaster to program flexibility when it is not needed. The end result is code that might score well on a templates test, but will be basically unreadable or alterable by any normal human.

    So there seem to be templates as used by programmers and templates as used by showoffs.
  • I feel the same way I feel about having voted for Obama.

  • It still has a billion and one corner cases to deal with. C++ does not need more stuff added to try and cover up the cracks, it needs a complete rethink of how to target the market needing high performance type safe programming.

    Thankfully Rust is targeting this, and has far less cruft involved.

  • No C++11, little STL (Score:3, Interesting)

    by JohnFen ( 1641097 ) on Wednesday April 30, 2014 @11:25AM (#46879603)

    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.

  • STL issues... (Score:5, Interesting)

    by wiredog ( 43288 ) on Wednesday April 30, 2014 @11:34AM (#46879691) Journal

    From Page 3 of this []:

    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:

    Syntax error: unmatched thing in thing from std::nonstd::_ _map<_Cyrillic, _$$$dollars>const basic_string< epic_mystery,mongoose_traits < char>, _ _default_alloc_<casual_Fridays = maybe>>

    • If template error messages bother you, use Clang. It outputs much saner template error messages.
  • In every project I have worked on it has been really important to try to write OS agnostic code. Some projects can afford a WinCE license, some projects would rather have a more stripped down RTOS type of thing so its really important to write as much code as possible without referencing the OS. C++11 makes that a bit easier with std::mutex and std::condition_variable. You get a platform independent mutex and with a little work a platform independent events/signal class (providing your target OS/compiler su
  • I had the most fun ever with C++ back when the original story ran. But it was too complex, too big and yet lacking standard ways of doing really very common things. Every library took a different approach. No standard libraries to do pretty much anything you wanted to in the real world. And it was always possible to shoot both feet off at once while doing something you thought was obvious and/or designed to make your code safer. Incredibly slow to compile. Compilers never supported the full C++ spec, o

  • Functionally, C++ compilers are great: type inference, templates, high efficiency, large scale compilations. C++11 fixes some problems. But the language has become hugely bloated, and the way new features are getting added is baroque. As for STL, few people seem to be using more than a small subset of it, and it's pretty much the same subset for everybody. Other things are still not getting fixed, like the use of include files.

    C++ needs a major house cleaning. The language could do what some other language

  • The view I get (from one who stopped at Fortran) is that there is an incredible amount of variety in how programmers look at a "language."

    Divergent opinions from experienced programmers gives me a different view of what current programming involves.

I've finally learned what "upward compatible" means. It means we get to keep all our old mistakes. -- Dennie van Tassel