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: (Score:2)
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)
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)
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)
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: (Score:3)
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)
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: (Score:3)
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)
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: (Score:3)
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: (Score:3)
No idea if you're still reading but...
Oh, you meant the language, not the library? Protected inheritance, then.
Well, one *could* attempt to justify on the grounds that visibility in-calass has 3 options, so why reduce it to two for inheritance... But yeah. I doubt anyone would notive if that feature disappeared.
Actually scratch that: there's probably enough nutcases out there using it because it exists. I doubt anyone writing any code that could be considered good by any measure at all would miss that littl
Re: (Score:3)
Anonymous
No one's forcing you to use those features.
Regrettably, you have to navigate around using them: It's like a control panel with the 40% of the buttons you push spattered among the 60% you don't.
Or, more precisely, the statements you know the grammar for are only 40% of what are in in the recognizer. The program that's trying to read your input and sort it into correct and erroneous now has a much greater chance of mistaking an error for a valid statement in the language.
Guess what happens when you say do 10 i=1.5 instead of do 10 i=1
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: (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
Re: (Score:3)
So what exactly is dated about it?
Re: (Score:3)
Re: (Score:3)
First one that came up with search results.
Re:Feels Dated (Score:5, Insightful)
Sure you can build a table with a hand saw, but with modern tools you can build it much nicer, and faster.
With modern tools you can build it faster, but the modern factory worker who uses a staple gun does not create a nicer product than the carpenter who uses a hand saw to create dovetail joints, and screws every screw in by hand to ensure the wood doesn't get weakened.
The same is the case with programming. Most modern high level programmers are, with all due respect, the equivalent of workers who staple particle boards together. That is often good enough, but should not be confused with what a master programmer does when writing kernel task switching code, or other robust code that isn't just meant to meet a single requirement but stand the test of time.
Re: (Score:3)
Re: (Score:2)
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: (Score:3)
You're forgetting that C++11 also introduces lambdas, which basically means you can inline-thread any command with thread([](){/*your code here*/}).detach(); All too easy. If you'd rather, you can keep the return value to join it later. Or you can use a future to make it even easier.
Why are you complaining about Make as if that's part of the language and the only way to build C++? (*boggle*)
Re: (Score:3)
Why on earth would a person *want* to have to go through all that mess just to launch a thread? *boggle* And what on earth is wrong with defining a queue on its own and passing by reference (or using it as global / namespace global if you'd rather)? Why should a queue be part of a thread object? It's not a thread, it's a queue.
Let the user put objects wherever they want, don't force them to extend a bloody class every time they want to thread something. : THAT feels old-school. If a person has to go th
Keeps getting better. (Score:5, Insightful)
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.
1M lines? Really? (Score:3)
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: (Score:2)
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.
Re: 1M lines? Really? (Score:2)
But certainly, working in an environment where the codebase is tens of millions of lines with 50+ developers that has been growing for approaching 20 years, the expectation is that, on average, a developer only produces a few SLOC/hour when testing/debugging/review/docum
Re:1M lines? Really? (Score:5, Funny)
They did a lot of copy/paste back in the day.
And even that is a better implementation of Templates than C++'s.
Re: (Score:3)
Also, you don't need half a whiteboard to write the full name of a type.
The build process is still shyte (?) (Score:2)
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: (Score:3)
Re: (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: (Score:2)
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
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: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.
Back in the day I did a lot of c++ (Score:2)
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++.
In Academic Projects (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
You can provide a custom allocator to Standard C++ containers to alleviate your fragmentation issues.
Performance? (Score:2)
Can you point to an example of how your container is more performant than the STL?
The truth about C++ (Score:2)
Standard Library is both a strength and weakness (Score:5, Insightful)
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)
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)
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 (Score:3)
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. (Score:3)
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 (Score:2)
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 (Score:2)
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
I use it, love it. (Score:3)
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 (Score:5, Insightful)
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.
Re:I love templates I hate templates (Score:4, Insightful)
But the nightmare is that many people are putting templates into everything so as to accommodate "future" flexibility.
Bad programmers love generalizing from one example. They do this in Java not with templates but with massive number of factories and class heirachies instead. Working with people like that is a massive pain in the ass regardless of the language. I'm sure there are other idiomatic ways of doing this particular antipattern in every language out there.
Re: (Score:3)
This reminds me of factory factory factories:
http://discuss.joelonsoftware.... [joelonsoftware.com]
Political comparison (Score:2, Funny)
I feel the same way I feel about having voted for Obama.
Re: (Score:3)
It's better than any of the alternatives?
It's still a mess (Score:2)
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)
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)
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: (Score:3)
Re: (Score:3)
Who modded this Insightful?
Not disputing parent's insight. But it's Funny. +5 Funny. Can't you people read, or did you not get the joke?
Hmmm... if only something (like a post) could have more than one attribute (like funniness and insightfulness) at the same time. Now that's a universe in which I'd want to live!
Using C++11 and STL in Embedded (Score:2)
Why use it? (Score:2)
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
some fixes, lots of bloat (Score:2)
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
View from a Non-Programmer (Score:2)
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.
Re: (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: (Score:2)
Re: (Score:2)
Honestly that will probably be more of an issue with the OS than using STL. Context switches suck.
Re: (Score:2)
Re: (Score:2)
A lot of people in embedded are still bit twiddling on an AVR. :-) Or a smaller ARM uCU like in the mbed board.
Re: (Score:2)
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: (Score:2, Insightful)
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: (Score:2)
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: (Score:2)
EA's "custom" STL implementation was mostly just a customized memory allocator.
Game companies use STL container objects all over the place in their code; it is considered safe, efficient, and familiar.
Re: (Score:2)
Okay, I'll bite.
What overhead, specifically?
Re: (Score:2)
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: (Score:3)
The library size for one.
Most of the STL is in headers. If that's causing problems with library bloat, you need to find a better vendor. Specifically what is too heavy? I doubt using std::push_heap on a statically allocated array would be smaller than if you wrote some heap code yourself.
I do not see why anyone is getting upset over my comment.
We're not upset, just skeptical. The reason being is that the arduino environment runs C++ happily, and you can pick and choose things out of the STL effectively. The
Re: (Score:3)
Re: (Score:3)
People like you are the reason that there's so many bugs in software these days and code is so hard to maintain.
From a less tongue-in-cheek standpoint, optimization (beyond choosing the proper data structures/algorithms and the like and thinking about where bottlenecks might occur as you go) should only be done in the following manner:
1) Run the program and assess the need. If there is no need, STOP.
2) Instrument the code and find out what is *actually* using up your CPU time.
3) Improve the code in the sect
Re: (Score:3)
Re:Meh (Score:5, Funny)
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: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
D *is* neat.
The only problem is lack of momentum.
Re: (Score:2)
Back to my usual joke then...
There are only 2 types of programming languages, those everybody bitches about, and those nobody uses...
Re: (Score:2)
Don't you mean
There are only 10 types of programming languages, those everybody bitches about, and those nobody uses...
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.
Re: (Score:2)
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,
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
Re:It's a turd that's slowly being polished (Score:4, Insightful)
#define if(x) if ((x) && (rand() < RAND_MAX * 0.9999))
#define true ((__LINE__&131)!=131)
#define InterlockedAdd(x,y) (*x+=y)
Yeah, C does give you the tools to turn debugging your program into a living hell. ;) With great power comes great responsibility.
Re:It's a turd that's slowly being polished (Score:5, Funny)
C: "Here's a gun. Don't shoot yourself in the foot."
C++: "I see you've been shooting yourself in the foot! Well, here's a different gun, rather like your old one, only we've added a safety and a trigger guard and oh by the way it now shoots 40 caliber shells containing fission-warheads."
Python: "Have a wiffle bat."
Comment removed (Score:4, Funny)
Re: (Score:2)
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.
Re: (Score:3)
Re:The more C++ evolves... (Score:4, Funny)
Re: (Score:3)
"auto" is there to reduce the typing -- that is all. Instead of writing MyContainer::const_iterator::value_type x = ... I can write auto x = ... because the compiler can deduce the correct type. It is not "too complex".
It is a convenience, like a "for loop" with a built-in iterator is there because requiring the programmer to write the boiler-plate required for a "for loop" with "do/while" is stupid. Your headline might as well read "C admits it is too complex with for() loop construct."
And C# is not col
Re: (Score:3)
I would fire coders using naked pointers.
I think this really reflects the flexibility of C++. You can write bare metal code and you can write high level application code ini the same language. There are so many situations where naked pointers are superior to smart pointers and the other way around, and if you get the two camps in the same room there is a good chance they will kill each other trying to convince the other side that their way is the one true way.
Re: (Score:3)
Alternately, you use shared_ptr to express shared ownership, unique_ptr to express sole ownership, and raw pointers to express that the pointer doesn't own the memory in any way. That can work.
Re: (Score:3)
Good news for you: size() is now O(1) in C++11.