Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

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

Unknown Lamer posted about 9 months ago | from the bringing-c-programmers-halfway-to-haskell dept.

Programming 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."

Sorry! There are no comments related to the filter you selected.

Feels Dated (5, Interesting)

Anonymous Coward | about 9 months ago | (#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.

Re:Feels Dated (1)

tree_frog (113005) | about 9 months ago | (#46878495)

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 (4, Interesting)

JustShootMe (122551) | about 9 months ago | (#46878719)

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 (0)

Anonymous Coward | about 9 months ago | (#46879053)

As what I suppose would be called a devops person, this is actually quite true. The best way to hand things these days is pretty much do the server and the ruby separately: use rbenv to install ruby from source and bundler to install all the gems. Do not install ruby or any gems from the OS packages. This way of doing things really does make things a whole lot easier when updating stuff.

Re:Feels Dated (0)

Anonymous Coward | about 9 months ago | (#46879093)

Ruby's a complete disaster from an operations perspective.

Re:Feels Dated (5, Interesting)

Vanders (110092) | about 9 months ago | (#46879675)

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 (-1, Offtopic)

Anonymous Coward | about 9 months ago | (#46878531)

I love when little videos autostart on my smartphone when I'm not logged in, which kicks me away from the site to a movie player app. Luckily I have enough karma to disable ads but wow, I would leave and never come back to this site if I didn't have karma.

Not just dated... (5, Interesting)

davecb (6526) | about 9 months ago | (#46878547)

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%.

Re:Not just dated... (2)

mr_mischief (456295) | about 9 months ago | (#46879035)

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 orthogonal. It's easy to see why some languages fall too far on the many ways side of things for some people, though. C++, Perl, APL, and Ruby are guilty as are others.

Yes, some languages are so complex they have a substantial and often ongoing learning cost. C++, Perl, APL, and Ruby are guilty as are others.

Subtlety can be really powerful, but too much can cause issues and lends to bugs that are difficult to track down. Obviously Perl is also far on the subtle side of the obvious / subtle line. C++ and Ruby live on the same end of that line, but maybe not quite as close to the end. APL... well, it's APL.

Agreed (3, Insightful)

Viol8 (599362) | about 9 months ago | (#46879097)

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.

Re:Feels Dated (1)

kodomo (1100141) | about 9 months ago | (#46878843)

It would be nice to see a kernel in java

Re:Feels Dated (2)

Keruo (771880) | about 9 months ago | (#46879365)

Go and have a look [cs.fau.de] at one then.
First one that came up with search results.

Re:Feels Dated (0)

Anonymous Coward | about 9 months ago | (#46879177)

Just out of curiosity, because i hear the "small bits via JNI" quite often: can you give me a (relatively) detailed example for a "bit" that you call via JNI ? I am really interested because i do a lot of development and have rarely seen these often quoted "bits" that would be worth the effort and that would actually profit.

Re:Feels Dated (1)

Noah Haders (3621429) | about 9 months ago | (#46879413)

here you go [wikipedia.org]

Re:Feels Dated (1)

Anrego (830717) | about 9 months ago | (#46879645)

Two common ones I've seen:

- Talking to hardware via serial
- Using some 3'rd party communication library/API which doesn't provide it's own binding (which itself would usually be JNI) or native implementation

Re:Feels Dated (0)

Anonymous Coward | about 9 months ago | (#46879181)

In my case I can't get used to STL algorithms (not very readable to me) and I find template programming painful. But I don't find templated dated, at least because java has something very similar (generics). What in particular does feel dated to you in the standard?

Re:Feels Dated (1)

Anonymous Coward | about 9 months ago | (#46879653)

I very seldom use any C++ library but Qt. Qt offers pretty much everything needed for developing a big application with lots of functionality, in that sense, I've always felt that Qt made C++ as usable as Java.

Now and then, I have to use another C++ library, like OpenColorIO, and that's just as much a culture shock as using a C library for me.

Keeps getting better. (5, Insightful)

Anonymous Coward | about 9 months ago | (#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).

Re:Keeps getting better. (5, Interesting)

Anrego (830717) | about 9 months ago | (#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.

1M lines? Really? (2)

Viol8 (599362) | about 9 months ago | (#46879189)

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.

Re:1M lines? Really? (0)

Anonymous Coward | about 9 months ago | (#46879303)

They did a lot of copy/paste back in the day.

Re:1M lines? Really? (0)

Anonymous Coward | about 9 months ago | (#46879361)

Maybe he is generating those lines from a higher language like http://nimrod-lang.org. I can tell you I use http://smc.sourceforge.net (a java program) to generate C/ObjC code.

Re:1M lines? Really? (1)

Jizzbug (101250) | about 9 months ago | (#46879479)

It is conceivable for a developer to write thousands of lines of code in a day when on a roll.

Re:1M lines? Really? (1)

Viol8 (599362) | about 9 months ago | (#46879545)

And then spend weeks testing and debugging it. It all evens out in the end. Even the most prolific coder would have trouble writing a million lines of code in this sort of time period. Maybe over the course of an entire career perhaps.

Simple (-1)

LWATCDR (28044) | about 9 months ago | (#46878351)

STL is great when you can afford the overhead.

Re:Simple (2, Interesting)

Crackez (605836) | about 9 months ago | (#46878375)

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:Simple (2)

bucket_brigade (1079247) | about 9 months ago | (#46878475)

There are applications where no overhead is always better than any overhead. Mostly stuff involving the simulation of physical processes. For example in computer sound synthesis and processing no matter how much computational power you throw at me I will use it up. A musician buys a computer twice as fast as the previous one? Great now he can use 10 convolution based reverbs instead of 5 or use that new virtual analog synthesizer plugin that emulates each transistor of some old korg synth perfectly and he will and his computer will choke just as before. Peoples needs are different. Just because you can't think of uses for extra CPU cycles does not mean other people can't and if your program wastes those cycles people will buy from someone else.

Re:Simple (1)

Anonymous Coward | about 9 months ago | (#46878651)

What makes you think that the STL is going to be slower?

Re:Simple (1)

Drethon (1445051) | about 9 months ago | (#46878525)

I've done a few timing critical programs but I'd prefer to offload that kind of tolerance onto dedicated hardware (simple example a serial UART).

Re:Simple (0)

Anonymous Coward | about 9 months ago | (#46878563)

If I recall correctly, many major developers for the previous generation of game consoles used custom STL implementations because the overhead was too expensive otherwise. Not that the PS3/XBox360 were anything special, but they're not slouches either.

Example: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

Re:Simple (1)

paskie (539112) | about 9 months ago | (#46878643)

A lot of people in embedded are still bit twiddling on an AVR. :-) Or a smaller ARM uCU like in the mbed board.

Re:Simple (1)

OrangeTide (124937) | about 9 months ago | (#46878681)

Who can't afford overhead and bloat?

The Hypervisor for those Embedded ARM SoCs. HYP mode is appropriate for a kernel that is only a few dozen kilobytes in size, and ARM's HYP mode doesn't play nicely as a Type-2 hypervisor (KVM, VMware, etc).

Plus your typical ARM SoC has several DSPs or microcontrollers on the chip.

I guess we're still not to the point where we can have one programming language we use for everything. I mean if you ignore plain old boring C as an option.

Re:Simple (1, Insightful)

tobe (62758) | about 9 months ago | (#46878749)

Unless you are bit twiddling on an AVR, or other micro, why not?

In which case you'd be sticking to plain old C.

Re:Simple (0)

Anonymous Coward | about 9 months ago | (#46879305)

And why is that? Why give up references and other useful C++ improvements just because you aren't going to use STL?

Re:Simple (0)

mkremer (66885) | about 9 months ago | (#46879677)

C99 pulls many of the non-object usefull C++ improvements in like references.

Re:Simple (1)

LWATCDR (28044) | about 9 months ago | (#46879617)

On a PC I would say everyone. On embedded it is not always an option. Even some ARM SoCs do not come with GB's of ram. Heck sometimes even c++ has too much overhead and you use c.
I do not see why so many people are bent by my statement. I happen to work a company that does a lot of works with M0, M3, and 8051 MCUs as well as Windows, Android, IOS, and Linux systems. On a PC I would never worry about using STL on an M0 or M3 I would, and on an 8051 I wouldn't even use c++.

Re:Simple (0, Insightful)

Anonymous Coward | about 9 months ago | (#46878439)

If you can afford the overhead, you can afford easier languages.

Re:Simple (0)

Anonymous Coward | about 9 months ago | (#46878911)

Hi there, have you been contributing to OpenSSL?

Re:Simple (1)

Stele (9443) | about 9 months ago | (#46879233)

Okay, I'll bite.

What overhead, specifically?

Re:Simple (1)

LWATCDR (28044) | about 9 months ago | (#46879639)

The library size for one. I happen to work at a company that works with MCUs like the M0 and M3, STL is a bit heavy for those. Forget about the 8051s we use for BLE. Not every program works on X86 based PCs running Windows, OS/X, Linux, BSD or some other OS.
I do not see why anyone is getting upset over my comment.

Re:Simple (0)

Anonymous Coward | about 9 months ago | (#46879253)

Overhead compared to what ? Not doing things at all ?

I think they should all be executed by Oklanhoma (0)

Anonymous Coward | about 9 months ago | (#46878371)

The Sooner the Better!

Java Ruelz!

Is it really C++ anymore? (0)

Anonymous Coward | about 9 months ago | (#46878383)

The concept of a standard library is just baffling.

STL (1)

Anonymous Coward | about 9 months ago | (#46878393)

You shouldn't teach STL anymore. The world has moved on to the C++ Standard Library and so should you.

It's a turd that's slowly being polished (1, Insightful)

twocows (1216842) | about 9 months ago | (#46878567)

I can't stand C++, but they are doing a good job of making it considerably less horrible with every iteration. If they keep it up, the end result will be a well-polished and beautiful turd that is, nonetheless, still a turd. I don't think it's salvageable; if we want something good that serves the same role as C++, it will need to be something completely new with similar goals. D sounds interesting, but I don't really know much about it other than it sounds neat.

Re:It's a turd that's slowly being polished (0, Flamebait)

Anonymous Coward | about 9 months ago | (#46878729)

Just because you need your hand held doesn't mean C++ is a turd. It means you aren't qualified to use it.

Re:It's a turd that's slowly being polished (1)

twocows (1216842) | about 9 months ago | (#46878871)

When I'm working on any project of significance (which isn't often anymore), I tend to write in C, so what you said is about as far off-base as you can get.

I don't know why you're fanboying about a language like C++ (or any language, for that matter; being a fanboy is stupid, and that is what you're doing), but I was just airing my thoughts on the topic, which is what TFS asked for. If you can't possibly comprehend why someone would deign to suggest your glorious C++ is anything but the result of angels crying tears of code, here's [yosefk.com] one perspective on some of its issues; it's certainly not the only one of its kind (but it's more in-depth and better-written than anything I'd come up with in a comment on /.).

Re:It's a turd that's slowly being polished (0)

bytesex (112972) | about 9 months ago | (#46879417)

Can you read? The person you replied to was not fanboying about C++ at all!? He was calling it a turd!

Re:It's a turd that's slowly being polished (1)

doti (966971) | about 9 months ago | (#46878773)

D *is* neat.

The only problem is lack of momentum.

Re:It's a turd that's slowly being polished (1)

twocows (1216842) | about 9 months ago | (#46878985)

On the other hand, the people behind it seem to be pretty active and passionate about it, which is a good sign.

Re:It's a turd that's slowly being polished (1)

alex67500 (1609333) | about 9 months ago | (#46879133)

Back to my usual joke then...

There are only 2 types of programming languages, those everybody bitches about, and those nobody uses...

Re:It's a turd that's slowly being polished (4, Interesting)

MadKeithV (102058) | about 9 months ago | (#46879171)

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.

Swiss Army Knife, huh? (0)

Anonymous Coward | about 9 months ago | (#46879329)

Could you be referring to this [distrowatch.com] ?

Re:Swiss Army Knife, huh? (1)

MadKeithV (102058) | about 9 months ago | (#46879347)

That's pretty much exactly what I was thinking of yes. But then using it as a hammer 90% of the time.

Re:It's a turd that's slowly being polished (2)

twocows (1216842) | about 9 months ago | (#46879669)

It was Bjarne himself who said that there are two kinds of programming languages: those everyone complains about, and those that nobody uses.

I'm sure that was said more or less as a joke, but it rubs me the wrong way. The basic suggestion here is that no language that reaches sufficient usage is going to be without its problems. That's fair, but I'm reading from it an implication that the criticism is purely due to its popularity, and that's not fair. There are a lot of problems with C++; some are fixable, some are too inherent in the design to be fixed. A lot of what could be fixed has been, and that's fantastic, but there's still plenty of room for legitimate criticism that has nothing to do with hating what's popular.

Regarding languages that "nobody uses," that doesn't necessarily say anything about their quality; some things just don't take off for whatever confluence of reasons. It remains to be seen whether D specifically will or will not, but from what I understand, it is very well-designed and avoids a lot of the design issues present in C++. That's really cool if true and I'm looking forward to seeing if those claims hold up.

Re:It's a turd that's slowly being polished (1)

RoccamOccam (953524) | about 9 months ago | (#46879313)

Why is that, I wonder?

Re:It's a turd that's slowly being polished (1)

BradMajors (995624) | about 9 months ago | (#46879161)

A problem with C++ is that it is possible to write some very very bad code in C++. I have worked with some companies that are now requiring the use of "C" instead of "C++" to avoid the production of bad unusable code.

While good C++ code is better than good C code, bad C++ code is much worse than bad C code.

Re:It's a turd that's slowly being polished (1)

TheRaven64 (641858) | about 9 months ago | (#46879549)

You probably haven't seen truly bad C code then. Really bad C code tries to do C++ templates using the preprocessor, where you define a few macros variables and then include a file that recursively includes other files to a depth of four or more, eventually resulting in the code that you wanted. The one thing this has over C++ templates is that you can read the output of the preprocessor and look for the bugs. Good luck fixing them thouhg.

same holds true for any language (1)

Jizzbug (101250) | about 9 months ago | (#46879671)

especially C

Meh (1)

Anonymous Coward | about 9 months ago | (#46878585)

I've spent 12 years coding C++ for a living.

IMO, The new C++11 stuff is mostly aimed at library developers, with an emphasis on template heavy libraries like boost and the stl (which are both fantastic, don't get me wrong). It offers some minor syntactic sugar, but mostly it doesn't have a lot to offer application developers. The committee has put off dealing with the features most non-embedded applications developers have long been begging for: garbage collection, and runtime reflection.

Re:Meh (2)

OneSmartFellow (716217) | about 9 months ago | (#46878691)

I don't know anyone who worries about garbage collection in C++11.

Re:Meh (4, Funny)

turgid (580780) | about 9 months ago | (#46878807)

I don't know anyone who worries about garbage collection in C++11.

Quite. The OS cleans it all up after the application exits, anyway.

Re:Meh (2)

MadKeithV (102058) | about 9 months ago | (#46879319)

I assume what GP means is std::unique_ptr, std::shared_ptr, std::make_shared, and then your own custom make_unique because they forgot that in the standard and a bunch of std::moves to convert the canonical unique_ptr from your factory functions into the shared_ptrs that you are actually using everywhere else.

And then fighting with the several iterations of only half-done C++11 implementations in recent versions MSVC compared to the better support in Clang while trying to keep your code compiling across 4 different platforms with as little use of #ifdefs as possible. May the noodley-appendaged one help you if you were hoping for easy multi-threading or unicode support.

I keep telling myself I like this language, but who am I kidding ;-). Seriously though, the language has made strides with C++11 and C++14, but it will always remain a minefield of ways to stab, shoot, detonate, incinerate and irradiate yourself in the foot, with some implicit casting to hands and other appendages thrown in.

Re:Meh (1)

bhlowe (1803290) | about 9 months ago | (#46879363)

Exactly: The OS releases the memory after the application sigfaults.

The build process is still shyte (?) (2)

AnontheDestroyer (3500983) | about 9 months ago | (#46878603)

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.

Re:The build process is still shyte (?) (2)

stewsters (1406737) | about 9 months ago | (#46878755)

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

Re:The build process is still shyte (?) (2, Interesting)

Anonymous Coward | about 9 months ago | (#46878885)

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:The build process is still shyte (?) (1)

robmv (855035) | about 9 months ago | (#46879075)

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) [ibm.com] (see Chapter3. An introduction to configuration files). It was easy to manage and the integration with the IDE was great [edm2.com] (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 time with C++, I loved them, today I can tolerate Makefiles but they are more archaic now than before.

The STL is too general purpose (0)

mark-t (151149) | about 9 months ago | (#46878625)

I think the STL is amazing, and I'm glad that it's a standard part of C++, but in my experience, it's usually far too general purpose to wind up in production code. This flexibility comes at a performance cost that, however modest it may be, can often simply not be worth the hassle of maintaining. I may use the STL during prototyping, or when first implementing an algorithm in code, but will often incrementally move to using custom types as a project develops.

Re:The STL is too general purpose (0)

Anonymous Coward | about 9 months ago | (#46879077)

I don't quite understand your statement that being too general purpose comes at performance cost. It's compile time binding after all and once compiled, traversing a vector is little more than increasing a pointer. We use STL in production code all the time in real time graphics applications. Although it does come with additional cost, but in my experience if such cost becomes significant, it generally indicates a deficiency in the algorithm or fundamental data structure design. It does require the programmer having an idea of each container's ideal situation of application. The less informed programmers tend to over use STL for convenience, and unknowingly make their algorithm O(n^2) instead of O(n) by choosing the wrong container.

It's trendy to bash C++ nowadays, but I've yet to see another language that can compete with C++ on performance and features, and best yet direct compatibility with C. I do hope that's a cleaner language that can supersede C++ without loss of its strength but so far none has come up.

Re:The STL is too general purpose (1)

MalleusEBHC (597600) | about 9 months ago | (#46879655)

I second a lot of these points. In the vast majority of cases, STL is plenty fast as long as you choose the correct container. If you're not able to pick the correct container, you'll be equally hopeless creating your own data structure.

In the absolutely performance-critical pieces, rolling your own data structure is often worth the cost over STL. However, many people mistake how many pieces are truly performance-critical. As Knuth correctly pointed out, premature optimization is the root of most/all evil. In most cases, you're better off with the consistency, readability, and reliability of STL over a homegrown data structure with unfamiliar syntax and potential bugs.

It's trendy to bash C++ nowadays, but I've yet to see another language that can compete with C++ on performance and features, and best yet direct compatibility with C. I do hope that's a cleaner language that can supersede C++ without loss of its strength but so far none has come up.

Have you tried C++11? It makes it possible to write much cleaner code than C++98.

c++ has greatly improved, also thanks to STL (4, Interesting)

kinkie (15482) | about 9 months ago | (#46878795)

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.

Back in the day I did a lot of c++ (1)

OzPeter (195038) | about 9 months ago | (#46878835)

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++.

ofcourse why not~ (0)

Anonymous Coward | about 9 months ago | (#46878841)

USA Independence Day 2014 [usaindepen...ay2014.com]

In Academic Projects (2)

Ajay Anand (2838487) | about 9 months ago | (#46878853)

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.

Re:In Academic Projects (1)

Yosho (135835) | about 9 months ago | (#46879087)

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?

Re:In Academic Projects (1)

Anonymous Coward | about 9 months ago | (#46879445)

STL usually isn't a problem on the CPU. As another poster pointed out, the running time is quite predictable - and pretty good.

But the memory overhead can be prohibitive in some cases. It tends to do many small allocations which in itself has a significant overhead and also leads to fragmentation of the heap. This is particularly nasty on systems without virtual memory.
Specialized classes can provide much better memory use.

Re:In Academic Projects (0)

Anonymous Coward | about 9 months ago | (#46879103)

So you wrote your own vector ?

Performance? (1)

Frankie70 (803801) | about 9 months ago | (#46879291)

Can you point to an example of how your container is more performant than the STL?

I don't like it (0)

Anonymous Coward | about 9 months ago | (#46878879)

As someone who is coming from learning C#, Java, and C++ as a student, then going on to use C++ in my first programming job ( 6 months so far), it is syntactically clunky, inflexible, debugging it is a chore and if you fuck up, you fuck up big time. Performance gains are negligible at this point, though I'm sure there is a lot of room for improvement.

Here is the fundamental problem... (0)

Anonymous Coward | about 9 months ago | (#46878929)

"They are always curious about what practitioners are doing these days." Those who can DO, those who can't TEACH. Get out and do some damned consulting, keep up on your industry, get your head out of your tenure and get into a job that makes you feed yourself on your skill in the field. Once you do that, then you have something valuable to teach. Other than that, you are just regurgitating someone else's opinions on things. Get some experience and make your lessons valuable to your students. By the way, I adjunct teach and my students ask the same things. I can actually answer them intelligently. I can give them a real-world example of the how's and why's of what I am teaching them in. With any guaranteed job, you stagnate in your knowledge to what is on the resume you were hired with. Tenure is the problem.

Standard Library is both a strength and weakness (5, Insightful)

PhrostyMcByte (589271) | about 9 months ago | (#46878957)

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#.

Re:Standard Library is both a strength and weaknes (-1)

Anonymous Coward | about 9 months ago | (#46879455)

Yeah, and a kernel, composite display environement and a web browser : let's continue to make languages full operating systems.

I never cared for STL (0)

Whammy666 (589169) | about 9 months ago | (#46878975)

I never cared much for STL. I don't find it all that useful. But I grew up learning programming thru assembly language and later plain-old C, so I'm biased towards keeping the languages at their core without the window dressing. There just isn't anything in STL that I can't replicate quickly using basic C/C++. It avoids a lot of compatibility/portability issues as well.

The more C++ evolves... (0)

Torp (199297) | about 9 months ago | (#46879019)

... the more I like other programming languages.
I'm sorry but all this "everything can be solved with a few more templates" mindset plus the feature creep remind me of only one thing: cancer.

I like it (0)

Anonymous Coward | about 9 months ago | (#46879065)

I actually took Stroustrup's advice and relearned C++11 as a programming tool in it's own right rather than just C with more features, and I've become much more productive, my code is smaller, faster, and more demonstrably robust, and life is generally easier, except for the part where I sometimes work with people who do not. C++11 and beyond make me happy; I like using them, and I no longer worry about the future relevance of the skills I'm using now.

Amazed at all the negative responses (1)

Anonymous Coward | about 9 months ago | (#46879131)

I liked STL then and I like the upgrades more now. Any project worth doing in C++03 is absolutely worth doing in C++11 if your compiler can handle it. C++11 is almost a superset of C++03, and the few places where it isn't are trivially fixed (e.g. auto is now a type specifier instead of a storage specifier). Nobody used auto in its old sense anyway.

Overhead is low enough that if you could justify doing the project in Java/Ruby/Python, you can absolutely tolerate the runtime overhead of well written C++ instead. Development overhead varies widely based on your developers' experience with the choices available. Don't send a Ruby user to write C++. Don't send a C++ developer to write Ruby.

STL containers are the best choice to use if your data structure needs fit with the STL design. Don't try to force-fit your internal representation just so you can use an STL container, but don't roll your own container to duplicate an STL one. The chance you'll beat the STL at its own game varies based on whose STL you use (Apple, Microsoft, or GCC libstdc++), but your odds aren't good for any of them, and anywhere you win will probably be overshadowed by the flexibility you lose. With vendor libraries, if you want to turn on exhaustive debug checks of container access, set a vendor-specific flag to build with the checking version of their library. If you roll your own container, now you either give up the existence of the checking build or you have to write the checking version too. If your custom container deviates from STL conventions, some STL algorithms may work poorly, if at all, with your container. Before rolling your own container, think whether you really need the minute speed boost you will get or if you would be better off adjusting the algorithm and/or data structure.

STL provides containers for most of the common purposes. Need a fixed-size array with known length? std::array. A heap-backed auto-resizing array? std::vector. A bidirectional linked list? std::list.

I think it's great (5, Insightful)

Stele (9443) | about 9 months ago | (#46879135)

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 (4, Insightful)

countach (534280) | about 9 months ago | (#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.

C is still poor at reuse and modularity (2)

bzipitidoo (647217) | about 9 months ago | (#46879249)

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.

Delayed. (2)

Chatsubo (807023) | about 9 months ago | (#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.

too heavy, too unreliable... at least for my uses (1)

Teunis (678244) | about 9 months ago | (#46879335)

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.

The STL is dramatically better now (2)

File_Breaker (16834) | about 9 months ago | (#46879451)

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 lambda functions are great. I'm not sure why there is so much hate for C++. Having worked with both C# and Java on several projects, I still think our C++ projects have the cleanest code and have the best performance before tweaking. I am one of the few developers that bounces back and forth between languages so I don't think it is a case of C++ people trying to write C# or Java, the people writing C# and Java are developers who write those only.

I use it, love it. (2)

mrthoughtful (466814) | about 9 months ago | (#46879553)

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.

I love templates I hate templates (4, Insightful)

EmperorOfCanada (1332175) | about 9 months ago | (#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.

Political comparison (1, Funny)

DoofusOfDeath (636671) | about 9 months ago | (#46879561)

I feel the same way I feel about having voted for Obama.

It's still a mess (1)

beelsebob (529313) | about 9 months ago | (#46879597)

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.

C++ admits it is too complex with "auto" for types (0)

Anonymous Coward | about 9 months ago | (#46879599)

Now you really have to think about this one, but ...

By introducing "auto" for types, C++ has admitted that it is too complex for human beings to understand. The "auto" type declaration means that only the compiler can figure out what to put for a new type. By using it, the programmer is saying "I have no idea what to put here, so I implicitly trust the compiler to do it for me."

This is similar to the IDE. Something like C# or Objective-C is so complex that it is collapsing under its own weight, so the solution is to give programmers an IDE that hides the broken mess of ad-hockery from the programmer. By giving programmers Xcode or Visual Studio, a company is admitting that their development tools are so complex that they can't understand or fix them. All they can do is put a band-aid over them in the form of an IDE.

The introduction of these crutches shows programming is getting too complex for human beings to understand.

No C++11, little STL (2, Interesting)

JohnFen (1641097) | about 9 months ago | (#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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?