Slashdot Mirror
C++ and the STL 12 Years Later: What Do You Think Now?
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."
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.
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).
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?
You shouldn't teach STL anymore. The world has moved on to the C++ Standard Library and so should you.
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.
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).
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:
davecb@spamcop.net
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.
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.
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.
A lot of people in embedded are still bit twiddling on an AVR. :-) Or a smaller ARM uCU like in the mbed board.
It's not the fall that kills you. It's the sudden stop at the end. -Douglas Adams
What makes you think that the STL is going to be slower?
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.
“Common sense is not so common.” — Voltaire
Unless you are bit twiddling on an AVR, or other micro, why not?
In which case you'd be sticking to plain old C.
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++, 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++.
I am Slashdot. Are you Slashdot as well?
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.
http://artlung.com/smorgasborg...
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#.
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.
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.
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.
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.
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.
Okay, I'll bite.
What overhead, specifically?
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.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
Can you point to an example of how your container is more performant than the STL?
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.
> no, yes, maybe (tagging beta)
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.
That's pretty much exactly what I was thinking of yes. But then using it as a hammer 90% of the time.
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.
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.
This comment was written with the intention to opt out of advertising.
I love templates when used in things like vectors, maps, sets, etc. Then combined with the new for loop iteration in C++11 it is great.
But the nightmare is that many people are putting templates into everything so as to accommodate "future" flexibility. But the simple reality is that unless you are programming a hard core library it is a disaster to program flexibility when it is not needed. The end result is code that might score well on a templates test, but will be basically unreadable or alterable by any normal human.
So there seem to be templates as used by programmers and templates as used by showoffs.
I feel the same way I feel about having voted for Obama.
It still has a billion and one corner cases to deal with. C++ does not need more stuff added to try and cover up the cracks, it needs a complete rethink of how to target the market needing high performance type safe programming.
Thankfully Rust is targeting this, and has far less cruft involved.
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.
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++.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
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.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
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.
Have you tried C++11? It makes it possible to write much cleaner code than C++98.
From Page 3 of this:
The C++ STL, with its dyslexia-inducing syntax blizzard of colons and angle brackets, guarantees that if you try to declare any reasonable data structure, your first seven attempts will result
in compiler errors of Wagnerian fierceness:
Best Slashdot Co
In every project I have worked on it has been really important to try to write OS agnostic code. Some projects can afford a WinCE license, some projects would rather have a more stripped down RTOS type of thing so its really important to write as much code as possible without referencing the OS. C++11 makes that a bit easier with std::mutex and std::condition_variable. You get a platform independent mutex and with a little work a platform independent events/signal class (providing your target OS/compiler supports C++11, may don't yet). Also beware: Visual Studio 2012's c++11 implementation of std::condition_variable is buggy, they have fixed it in 2013.
Furthermore, If you are working with the STL and algorithms you should really go over std::function and move semantics. std::function helps lambdas, functors, and callbacks look the same and all the sorted containers will accept a std::function as a predicate. Move semantics help avoid needless copies for objects that are on the free store.
So as for practicality from one practitioner: Use of the cool new features of C++11 and the STL scare some people. I don't mean that offensively, it's not without merit. What I have experienced is that the amount of whining someone does about C++11 and the STL is a function of their age. Why? Because an inexperienced person may try to grow a vector in a interrupt or not understand what template bloat means, probably because they have never experienced missing interrupts or running out of codespace. Why is this caution bad? Because you can get a 1+GHz/256+MB SOC with nearly unlimited code space for less than $10. There still needs to be balance, and a good understanding of which threads are real time and which aren't, but an average dev can be much more productive using the STL and new features of C++11 than someone jumping through hoops to avoid using the STL.
Personally, I don't like auto_ptr and would avoid the smart pointers. They are really cool in trivial applications but it is as easy to screw up mem management with auto_ptr as it is with naked pointers in more complicated situations (IMO YMMV).
This is generally what I have found, too.
The best uses of C++ I have seen were simple and fast since they were really just vanilla C with classes.
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, or supported different bits of it on different platforms.
The trouble is, I can't see any compelling reason to use it for anything much these days. Maybe the latest C++ is better - but given what I know of the language I suspect the main criticisms I have of it must be still valid.
Use cases where you need that insane low level of power and control while retaining a high level language syntax are not common at all.
Can anyone give an example of where C++ really shines these days over other languages?
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 languages did and support "old" and "new" syntax, sharing the same backend and generating compatible code. But the current incremental modifications to the language will just doom it in the long term.
(The "D" language actually appears to be such a "reboot" of C++, but I haven't used it enough to know whether it could really serve this function.)
Staying with rudimentary C/C++ gives you cross-platform compatibility. And it may come as a surprise, but there are still a lot of legacy systems out there that don't have the latest and greatest C++ libs. As for map libraries, you think those didn't exist before STL?
When all else fails, run.
Honestly that will probably be more of an issue with the OS than using STL. Context switches suck.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
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.
C++ is to C as Lung Cancer is to Lung.
Trolling is a art,
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.
That's funny, I was reflecting on my days working with EASTL too. But yeah, it's all about memory allocation. People don't realize how incredibly tight memory was on a Wii/PS3/Xbox 360.
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. There's plenty in there that will run on raw arrays, and I'd be surprised if it generated more code than a by-hand implentation.
SJW n. One who posts facts.
I think "STL" here refers to those parts of the C++ standard library descended from STL. These tend to have a better reputation than, say, the pile of unidiomatic bloat that is .
I've worked with a lot of embedded system where memory was under 64MB and that was recent stuff. You have custom allocators for everything so that you can track with tools where every single MB went. For us the STL usually gets wrapped or replaced to prevent non system engineers from doing really stupid crap with it ( the things I've seen...) we need to account for all that memory. Mostly changes were things like fixed size vectors.
Anyways, look at iOS dev for an ARM SoC. Still today, developping an app that uses over a 100MB of RAM is pretty iffy. You'll get low memory warnings on plenty of iOS devices. I usually had to develop with managed languages and I really, really missed the ability of having custom allocators to track every single byte. It just makes memory profiling incredibly time consuming and imprecise IMHO with most of those languages. Some of those did have really good memory tracking tools but it wasn't ported to the iOS version, others just plain don't have detailed memory allocation tracking.
In which case you'd be sticking to plain old C.
Except you don't since G++ supports the AVR stuff just fine. In fact the arduino environment is C++.
SJW n. One who posts facts.
Another big use for JNI that I can see is reusing existing application logic written in C or in C++ on a platform that prefers that front-ends be written in Java. Android is a well-known example here.
First rule of optimization: Don't.
Second rule of optimization (pros only!): Don't yet.
The thing about STL is that it's generally quite fast on its own, and if you ever need more speed doing a particular operation, you can just extend it to access its underlying datastructures. As a general rule, though, the only way you're going to get better performance is doing operations that are "dangerous in general". Which may be fine in your specific case, because you may know enough about your data to know that you don't need, for example, bounds checks or whatnot. But it should only be done where there's a known need for it.
It should also be noted that STL algorithms are generally pretty optimized, and that a lot of programmers aren't really all that good at optimization on their own, so it can actually increase performance sometimes. Example: if I grep in the g++ headers I see __restrict__ used 65 times. How many programmers do you know that make regular use of __restrict__ where they really should? I'd bet it's in the 10% ballpark. But it has a huge impact on array performance in many circumstances.
It should further be pointed out that a lot of the evolution of the language is focused on making there be no penalty from using containers vs. rolling your own implementation with pointers. For example, move constructors.
Lastly, the obvious: STL code Just Works(TM). Rolling your own is a great way to introduce unexpected bugs. Doubly so if you rely on a raw pointer-based implementation.
When was the last time you ran anywhere? I mean with your own legs, not by pressing 'X'?
I can tell you that the ARM programmers are really tight for space and wish they could use STL but it is just too big. I am maintaining an MFC Windows codes base so they did not use STL. Maybe I should have just said that STL is great and you should use it if you have the resources. I do think STL is great but again if you do not have the resources you can not use it.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Case in point: I compiled hello world using for a Game Boy Advance. After I added -Wl,-gc-sections to remove unreachable code, it still took 180,032 bytes out of the system's 262,144 byte main RAM. Much of this space was dedicated to libstdc++ bringing in the libraries for "locale" (date, time, and money) support, even if a "locale" sensitive object never gets printed.
C++11 is really the first reasonable version that you don't have to fight with to do anything.
Until C++11, all we had for smart pointers was the abomination of auto_ptr, with its completely screwed up design. It's a miracle if you could code correctly using auto_ptr until you gained long experience with its pitfalls. Yet I don't even regard C++ code written without smart pointers to be acceptable, and it certainly misses the whole point of C++. I would fire coders using naked pointers. OK, after boost showed up and got reasonably mature, you could fight with corporate to get permission to use it in order to get shared_ptr. Or you could try to roll your own, and reproduce all the development mistakes yourself.
C++11's shared_ptr and unique_ptr make all the difference.
Other than that, we FINALLY have nullptr rather than the abomination of using literal 0, or a macro which amounts to the same thing, to represent null pointers. We can finally overload functions on int and pointers.
Move-semantics and rvalue references are a big efficiency breakthrough, too. As is uniform brace init, which fixes the classical stab in the eye where a temp which was a default class init was interpreted as an invocation of a function taking no arguments instead.
class C { ... }; // properly default-constructs a C // interpreted as a call to a function C, fed to the function F
C x = C();
x = F(C());
Now you can just do x = F(C{});
What makes a language good? I'd argue that most will let you do what you want. And you may be proficient in any given language. But what makes one language better than another is the following.
When you are given someone else's unintentionally screwed up code, is the language easy to understand so that you can find the bug(s) in a reasonable amount of time? Does the language disallow questionable code so that the other guy is less likely to screw up in the first place?
I'm fairly certain that if I'm the only person working on a project C++ would be great. Not my first choice but not bad by any stretch. But if I have to debug someone else's code, C++ would not be fun.
"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 collapsing under its own weight. Any programmer, no matter what language they program in, that is not using a modern, intelligent IDE is wasting time and money -- they are a hack (in the worst sense of the word) and not a professional.
the growth in cynicism and rebellion has not been without cause
The STL performance spec for size() function for std::list is undefined. Gnu and Linux want to keep std::list::splice() constant time and so they have made size() order N. Microsoft has decided to keep size() constant time and has made splice() O(N). I don't use splice, so I was adversely affected on Linux. But worked around it by creating a counted list class.
I think sometime back STL changed the spec seriously in a non backward compatible way. Something to do with std::set/map/multiset/multimap::iterators. They made the iterators returned by find(), upper_bound() and lower_bound() const_iterators by default. (Or something similar). All prior code that was using iterators had to adjust. Most of my fellow coders used const_cast() and got around it. I never use const_cast(), so I had to do some significant refactoring, rearchitecting, reimplementation.
But for these two issues, STL is working very well for heavy duty computation in finite elements, CFD, computational geometry and such fields. Scales very well. I have had maps and multimaps running into tens of millions of members and then I do insane amount of insert() s and erase()s. Works well. If you give weight to the amount of CPU these codes chew up, we form a significant market share. On unweighted plain numbers, we are probably dwarfed by the number of web applications, ruby people and java hackers.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
When I started at my current job 7 years ago I came from C and C++ to Java. I liked Java a lot. We had a little bit of C++ and C utilities but our main application was Java.
Then we needed something running realtime and I went back into C++. It took quite a while to make a relative simple application because I had to start from scratch with basic network and serial interface handling. Also I had to make an interface protocol to speak with the rest of the application writen in Java.
Then we started another much larger add on which needed high performance. C++ was the only realistic choice. I estimated the time to write the code would be 3 times that of our prototype written in Python. I was wrong! It is hard to meassure because the prototype and the production code did not do the same thing, but it certainly did not take 3 times the efford to write it in C++ than Python. And compared to Java it was not much harder to write it in C++. Debugging might be a be harder, but we have no problems with memory leaks, segmentaion faults and other memory issues being the usual problems haunting C++. And note: Java and Python also have memory leaks due to dangling references. These can be very hard to find, too.
C++ is not 3 slower to write code in than Java and Python as I expected. It is almost 1-1 - as soon as you have written the framework of your application. One of the major design rules which definitely helped us was: Avoid multithreading ! Instead our application is split in processes, communicating with sockets. Each process is a loop around a select() call. The split in processes makes it much easier to spot errors. Each process is run in a while loop in a screen such the system can recover from a crash of one of the processes.
We avoid memory leaks by using (now deprecated, I know) std::auto_ptr. It is implicit in our code that the owner have the auto_ptr, while all others jave a plain poitner to the object. The owner have it as a auto_ptr. shared_ptr are rarely needed.
Another thing: We write Java like rather than C like C++: We do not use pointer arithmetic. We use STL or our own containers. We avoid unsafe typecasting. We try to code against interfaces rather than implentations and all the other best practises of object orientated programming. Stuff you only learn properly by coding Java or another OO language.
The network handling in the C++ parts worked almost flawlessly, old bugs keeped appearing in the Java network code. This was because Java per default rely on thread for everything: Befoe select was added to Java you needed a thread for reading a thread for writing for each TCP connection. And getting the threads to work together quite right is hard - in any language. Then it is easier to have one thread and events when the socket changes state.
The major issue with C++ over Java and Python: "Batteries are not included". And no STL is no near the standeard libraries in Java and Python. Not even boost gets close. But in our case, once we had the basic eventdriven framework with sockets and buffers, connection handling build up of logical classes around a select loop it was easy to add new functionality. C++ is not good for writing large monolithic applications because it can be very hard to localize errors - Java handles that much better because it is much easier to localize errors. But Java (and Python) still uses way to much memory when you represent data as objects.
Another thing C++ has is ofcourse templates. It is a really good alternative to object orientated techniques for writing re-useable, generic code. The good thing is it all bindings happens compile time. That means both that many errors are caught compile time, and that the compiler can optimize seemingly very expensive code. When calling a virtual function in an interface the compiler very rarely can figure out which implementation it really is and do optimizations.
All in all: C++ is a good, powerfull and high performance language - but it requires a lot of de
I can tell you that the ARM programmers are really tight for space and wish they could use STL but it is just too big.
I'm still curious how: I've not programmed on small ARMs, but I have used AVRs. They're not exactly generous for space. You keep saying it's big and takes up resources, but I'm curious how.
Take the following rather silly code which implements a global pqueue of ints. Sort of what some embedded code might look like:
How much bigger is that code in the resulting ASM than writing a heap by hand? I had a look at the ASM code in gcc, and to me it seems pretty tight. Likewise with functions like min_element, and so on.
Sure if you pull in stringstream for de/derialising things then that's big. I doubt anything in algorithm, numeric, functional and so on would be substantially larger than hand-coded versions of the same.
SJW n. One who posts facts.
That is why you use Qt.
In all my years of using slashdot I can't recall a thread where I learned more from others just by reading comments. Very good stuff here!
Good news for you: size() is now O(1) in C++11.
SJW n. One who posts facts.
Where I work we build apps in C on top of a home-grown platform. Various project managers have let developers use C++ when they wanted to, and without fail, the C++ code is much harder to support than C code. Part of it has to do with the C-based library and its persistence model, which isn't very C++-friendly, so the C++ stuff tends to build its own concept of what an object is in this context, and it invariably adds layers of complexity to what is a pretty nice and conceptually very simple C-based app platform. It also doesn't help that the dbx debugger on the AIX platform we run doesn't handle C++ objects nicely. Essentially, it's really hard to know what C++ code in this environment is doing. And without a powerful C++ framework to take advantage of the language, the language itself is more trouble than its worth.
I've done some work in Java, and was pleasantly surprised. To me, it turns out that the nice thing about Java isn't its object orientation. It's that it doesn't count on the compiler having to know the internal structure of class objects. No .hpp files, no need to define everything twice. And garbage collection (if it really works...). I still prefer C - since I have a good sense with it of exactly what is happening at any point in my app. But when I have to use it, Java's not bad. C++ still gives me a headache.
Posted from my Android phone. Oh, I can change this? There, that's better...
Not all "Embedded ARM SoCs" are monsters that run Linux. They also include Cortex M, which usually comes with no more than 64K-96K of RAM and 512K-1M of flash on the high-end M3/M4 models. On those you generally want to avoid the kind of programming that throws around calls to malloc/new like they were junk mail.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Not to mention the minor detail of lacking any sort of tty console hardware to use those iostreams on.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
That was including a short tty driver I hacked up for the GBA.
not really - what you need is to pick a few libraries and pull them in. Unlike other languages where you use what comes with your IDE, with C/C++ you are encouraged to find and use reusable libraries.
So if you want XML, get tinyXML and use that. If you want http - boost::asio or curl. Web Services (REST or SOAP?) gsoap or boost::asio or civetweb/mongoose, and so on.
This is a huge advantage. If I want an embedded webserver in my code then I'll include civetweb in it and with 4 lines of code and 2 c files, I have my code answering http requests. It will be limited in functionality, but that's ok as my embedded server only has 40k added to it by doing this. If I want something much more featured, I'll use a different server library.
If I want JSON, I'll go grab a JSON library, good luck using JSON in your that didn't see fit to include a parser for it. I would like to see boost wrappers/reimplementations of many common libraries like XML or SQL, but ... maybe one day I'll have a go at contributing one.
The only disadvantage to this is finding which library is the most suitable for you.
PS. async in cpp?
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.
But don't worry, that'll get fixed Tuesday in the monthly update to all major versions of the libraries! Even those lowly .NET 1.0 programmers will get the updates!
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
| By introducing "auto" for types, C++ has admitted that it is too complex for human beings to understand.
No, it's admitting that working with libraries and systems without 'auto' require mental effort by humans that shouldn't be necessary to exert.
| 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."
Indeed, and there's nothing wrong with that.
Like f(g(something))
The compiler figured out that the static type constraint of the return value of g() is compatible with the argument of f(). Why is that OK (which has been fine since neolithic ages), but
auto z = g(something)
f(z)
not OK?
Simple type inference is decades overdue, and it reflects an actual intent of the programmer: "declare a variable which can hold the return type of some function". The point being that with development, if that function's return type changes (or is implicit through complex templtatizations), with C++11 type inference (auto and decltype), the program continues to compile and work cleanly. Without 'auto' and 'decltype' used appropriately the programmer can't express his actual intent.
I use C++11 now and think it's a good improvement. BTW, the Eigen matrix library for C++ is fantastic. I'm a computational programmer at times and I've waited many years for something this good and easy.
I felt your pain, but the practical state of C++ is much better today.
A great application which I use is computational code with modern C++ template libraries for the problem domain. Fortran 2003 is also highly competitive (and in some cases superior) here.
What is "Big Data" analytics? Computations at the limit of capacity. Constant factors really do matter---more efficient computations in space and time mean you can ingest more data and that gives better models. Markov Chain Monte Carlo and other stochastically iterative/converging machine learning algorithms are not trivially parallelizable, and doing so induces a very large overhead in programming complexity.
I've used C++ since 1997.
Don't care much for the STL. Its syntax is nice, and I don't mind the size overhead much, but the compilation time is noticeably increased the more templates you use.
C++11 has a bunch of syntax improvements, like "auto" and inline class member initialization. I think I'll use it for most of my future programs.
Speaking just about STL, I'd have to say it's one of the worst designed container APIs I've worked with. It just goes out of its way to make your code painful to write and hard to read.
Suppose you want to determine if a collection c contains an element e. In any other language, you'd write something like c.contains(e). But the STL designers, in their infinite wisdom, decided instead you should write c.find(e) != c.end(). Because that's just so much more readable. Suppose you want to determine if a string s ends with some suffix t. In any other language you would write something like s.endswith(t). But in C++ you write s.rfind(t) == s.size()-t.size(). I think? I'm not 100% sure I didn't make a mistake in there.
C++11 tried to fix some of the worst aspects of STL, but they didn't redesign it from scratch, which is what it really needs.
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
Features are added and behavior is changed for the sake of changing, with no benefits to any software quality whatsoever.
Spoken like someone who doesn't know what they're talking about.
No benefits to software quality? Point out any new feature in C++11 that was added that didn't have a reason. (I would be very interested in fact, as I can't think of any off-hand); the newly added features are done with specific problems in mind. They might not be the problems that YOU encounter, but someone else has.
Compared to what it used to be, C++11 is very nice. But it's still one of the ugliest, most obfuscated languages for general production work. I realize why this is so - speed and memory concerns still make it the go to language (har) when you really care about either of those.
I used to use C++ constantly. But it's very rare now that we can't just write what we need in C# (medium to large scale) or Python (small to medium scale) in 1/3rd the time (or 1/10th for anything GUI). And for embedded we're still using pure C.
So we use C++ in that very rare intersection where we have some complexity and speed actually matters. Most recently in an image pipeline where the app itself is all C# and the heavy lifting (billions of pixels) is done in non-managed C++ (they didn't want to require GPU). It was okay, but using C++ and C# together makes you really aware of just how much administrative overhead C++ has, though the classes certainly made things better compared to pure C.
So... it definitely has a niche, but it's not normally the most efficient way to do things, for implementation speed, cleanliness, or maintainability.
Unlike other languages where you use what comes with your IDE, with C/C++ you are encouraged to find and use reusable libraries.
Encouraged is a funny word, seeing as there's no other choice... but that's beside the point.
Having to dig out multiple libraries to make any non-trivial project is a pain. Having to worry about TinyXML's lack of standards compliance and proneness to buffer overruns (in an older version at least, not sure if it's still there), gsoap's godawful API, wrapping libpng's setjmp/longjmp error handling in exceptions, wrapping libcurl with RAII objects, or XYZ's exception safety, etc.
There's something nice to be said about having a very cohesive set of libraries by default. Same level of quality, same familiar style, same level of documentation, same integration with the rest of the library and language. C++ getting these things would not force you to use them, it would simply let devs bootstrap their apps a lot quicker, and far more robustly.
But still they didn't remove the need for those pesky header files. Aaaahrrghgh
I'm really done with typing every function declaration twice!
If Pandora's box is destined to be opened, *I* want to be the one to open it.
The best programming languages work like and use the same parts of the brain that reading and writing do. It is no surprise that the language of mathematics reads left to right, uses Latin symbols, and roughly follows European languages in grammar and syntax. (In certain parts of the Arab-speaking world, some mathematical expressions are written left to right, but this is not universal.)
As the syntaxes of programming languages become more elaborate, the cognitive load involved in programming increases. As other parts of the brain become involved, programming error rates increase, not to mention the common sense notion that completely learning the language becomes unachievable for most people and every programmer works with his or her own subset making code maintenance difficult.
C++ with its feature-packed templates makes people who love a language to have every concept from computer science packed into it happy, but it doesn't serve programmers and hence humanity very well.
The ideal programming interface is you telling the computer exactly what you want it to do in English, not the the opposite. We're decades away from an AI that can automatically write code, but making the programmer's link to the computer more difficult to convey unambiguous instructions seems to be going in the opposite direction.
Thanks, But I am not reverting my hack. But in future I will be a little bit more confident in using size()
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
How'd you manage to do that? A sincere question.
In all my years of coding, I've never been able to "un-taint" my mindset, so learning any new language has always boiled down to either "learning it like C, but <differences>" or "learning it like perl, but <differences>"
I don't anticipate moving to C++11 in the foreseeable future, and certainly not porting code that already works, unless _maybe_ it is being completely redone. STL and Boost have some useful stuff, but good judgement is required to use either.
I use STL containers:
- They are less trouble for all concerned than reinventing them, and they offer some useful features, like builtin sort()
- I never, ever use custom allocators: that is my dividing line between useful and too much trouble compared to writing my own collection, in the rare situations where they are needed.
- I will subclass a container, rarely; I'm more likely to embed, providing I don't have to copy paste too much API.
- I never, ever use STL algorithms, for any purpose. It's easier to just write a for loop if I need one, and I get something everyone can understand.
I very rarely use Boost classes, and only simple ones like auto_ptr variants.
- Boost is much more on the side of way too much trouble and risk for any benefit it provides.
- Most classes look like programming exercises using techniques (template metaprogramming) that I would never allow in production code.
- Boost is even worse than STL for creating code that saves a few lines but takes as long or longer to write and is unreadable, undebuggable, and unmaintainable.
In general, if advanced templated code doesn't work or needs to be extended, I'd rather spend my time rewriting it than trying to "fix" it.
I have to wonder if anyone would bother creating C++(latest) if they didn't get tenure/job security/prestige from being on a Committee. More advanced languages already exist that have all these features; why try to bolt them on C++, where they were never intended to be? Did we learn nothing from all the abortive attempts to add garbage collection? Why not work on C++ / advanced language interop and actually make things better?
SOME embedded systems come with GBs of RAM, many of them do not. C++ can easily triple the RAM use if the developers are not mindful of what it is doing. Some styles of C++ can also screw up caching badly, as templates may reuse text code but they don't usually reuse object code. Sometimes even something trivial like using an exception drags in a ton of overhead code. Thus things like Embedded C++ which are subsets of C++ designed for smaller systems.
STL is template based. That means if you use the same template for different types then it will generate duplicated object code. Much like using a macro generates duplicate code. Templates have more type safety and rules than macros but for many compilers they are not necessarily more efficient. Sure, bigger code may not always mean it's slower but it can have a big effect on speed in a few of ways. First it means the cache is less efficient as there's more code in general. Second, two copies of the same routine means that even if the first copy is cached that it won't help you out when you call the second copy. This is not such a big deal on PCs because they have such large caches, and multiple levels of caches. Third problem is when you're on a paged system and more program space means more memory has to be swapped in and out, especially if you're context switching between multiple processes.
Same sort of problems arise you get if you try to forcibly inline everything.
Being nice doesn't make you wise. Mr. Stroustrup is certainly intelligent: I've read his apologia*, and have no doubt he was following a good lead, and wasn't planning to fail.
--dave
[* See https://en.wikipedia.org/wiki/.... I'm using it in the religious sense]
davecb@spamcop.net
But use it well. A big problem comes with using STL blindly as a one-size-fits-all solution. These are theoretically optimal algorithms, but that does not mean optimal for ever problem, and definitely not optimal if used incorrectly. I have honestly seem rather smart people otherwise do stupid things with STL, like use std::map where the key has only 8 possible values (use a basic C array instead, or a vector if C scares you). I have even seen std::map used in a case where one and only one element was ever in the map at one time (I have no idea what they were thinking, I can only assume that the code requirements must have changed over time). I have also seen people force things into STL merely because they want to use the convenient find/sort algorithms.
A big problem I used to see a LOT was using STL to contain the elements when it could have contained pointers to the elements. This means lots of copying, and if the elements are very large this does have a noticeable effect on performance if elements are being moved arounda lot. You don't see this as much in C as C devs tend to use pointers rather than lots of struct copies, whereas the copy contructor is ingrained deeply in C++ and used constantly. Some of this comes because C++ tries to hide the fact that copies are being done, so novices are often unaware that they're writing inefficient code.
I have had several cases of going through and optimizing C++ code and getting very measurable performance improvements by doing only changes that could have been trivially done when the code was first written. However there's this nearly religious fear some devs have of ever optimizing code because once in the distant past they heard a professor say something vague about premature optimization and now they avoid all optimization. So their rapid prototyping style is also the style they use when performance matters.
You can use C++ on embedded systems, you just have to be mindful and not program like you were on a luxurious PC of the latest model. Instead, avoid the extra features like exceptions or STL or RTTI, or if you do use templates try to have containers of pointers to objects to avoid copying overhead.
C++ is a great language when it is used as a better-C-than-C. Better type checking and safety, convenient auto pointers, basic classes with basic inheritance can greatly simplify a lot of code, as well as namespaces. Even virtual functions are fine.
Templated code is not good about sharing space. Or more specifically, the compilers and linkers are good about recognizing that there is essentially identical code that could be combined to save space. STL is good for code reuse in the sense of the text you write, but it is not necessarily good in reusing object code.
Some of the C++ class libraries that existed before STL were much more efficient since they weren't heavily templated. Thus you had an actual object code library.
Third rule, ignore the people who say don't optimize. They're the reason everything is slow today, and why with a computer that's a thousand times faster than it was twenty years ago, Word does not feel any faster than it did twenty years ago. Optimization is done all the time and with good reason. Programs that put off optimization too long get a reputation amongst the customers for being slow (ie, firefox before they took time out to optimize memory usage a few years back). I have been on some projects where the customers were complaining, or where they had specific timing requirements. I have worked on projects where a major bullet point in the release notes for customers was about improved performance.
Remember, optimization does not mean only going through existing code and finding ways to tweak it. Optimization can also mean writing it down the first time in a way that is faster than a different way. Even if you're following the religious belief to Just Use STL you can pick the right container to use, vectors are vastly faster than maps for example, chose an initial vector size rather than let it grow by chunks as you insert at the end, stuff like that.
Too many people though code for the final production code as if they were doing rapid prototyping.
Sure, you can say you work with a lot of bad programers so STL does a better job on average. I have also worked with a lot of bad programmers who used STL where the code was easily improved in performance by changing how they used STL. STL is a tool, and like all tools they have specific uses and are not the perfect tool for all situations, and a good tool user needs to know how the tools work and when to use them and when not to use them.
So dammit people, optimize your code. It is easy to do and your customers will notice.
No, more things should not be built into a language. There's nothing wrong with third party libraries. Standard libraries should be short and sweet, only add stuff once they're well used and tested for a loooong time. C++ added some stuff a bit too early I think, or things that should have been left as third party addons were incorporated. A standards body is the wrong place to look if you want something well designed.
C++ is a religion, and STL is one of its major sects, as you can tell by the ridiculous arguments that break out.
By why would you do that typing? Your IDE should be doing that typing for you. Java isn't verbose when you have Eclipse to do your typing for you.
"This mission is too important to allow you to jeopardize it." -- HAL
On an Atmel AVR with 2K of RAM, I found C++ works well. Of course you have to be conservative about using language features.
I can see how with multiple programmers at different skill levels its dangerous.
In principle with C++ you don't pay for what you don't use.
Just for fun, I tried the same experiment on one of our DSPs, and it pulled in just over 64K. I think our library is generally leaner in the locale department. In fact, I didn't see any locale data linked in. Most of what it pulled in looks to be actual ios/istream/ostream stuff, basic_string<char> and basic_string<wchar_t>.
Program Intellivision!
It seems like writing a terminal driver is a rite of passage. :-) I did one for our DSPs, and most recently, the Intellivision.
Program Intellivision!
Which C library is that? Is it under a free software license, or is it included only with one of those $6000 per seat (source) compiler toolchains that only professionals working for established companies in the richest countries and students and faculty at accredited postsecondary institutions can reasonably get their hands on? StoneCypher used to be a big proponent of C++ using the Green Hills compiler, but there's no way the median hobbyist developer could afford that.
And most recently I wrote a terminal driver for the Nintendo Entertainment System that wraps a 6502 proportional font library that I had written a few years ago. I'm using it to print the results of testing software floating-point arithmetic code in my port of Cookie Clicker to the NES.
You do have to be sure to compile with full optimization enabled, though, for STL to have a minimal hit. I use STL quite happily to do things I only too eagerly rolled my own implementation of years ago, and then clung to, even if it wasn't a perfect fit. For example, for eons I carried around this AVL tree implementation I wrote for a data structures class, and used it to implement associative containers, just so I wouldn't have to do it again. These days, it's simply map< yadda, yadda > and I'm on my way. I'm willing to bet map<> beats that creaky old AVL tree any day.
Without optimization, the STL containers can slow down quite a bit. I've heard the effect is especially large on some versions of MSVC++, since they have special debugging versions of the iterators that incur their own cost penalties in return for other checks. I wouldn't know; I do all my development under Linux or for embedded processors on bare metal.
With optimization on, I rarely if ever notice a performance issue due to STL. I do run into the occasional limitation, such as needing an actual resizeable 2-D array-like structure. (A vector< vector< ... > > doesn't cut it, because resizing the inner dimension doesn't resize all rows.) But, that's more exception than rule.
My biggest complaint about C++11 is that I won't realistically be able to use it for another few years. Grrr.
Program Intellivision!
STL is template based.
Yes it is.
That means if you use the same template for different types then it will generate duplicated object code.
This isn't necessarily true. Well-written templates will defer to base implementations that avoid duplicated code. For instance, templated containers of pointer types should all wind up using the exact same implementation, with the type-safety only being there to keep the compiler happy. That same implementation may be usable for any trivially-copyable data of the same size.
Templates and macros are really not even close to the same thing.
I unfortunately claim ignorance on the license for the runtime. I know some of my employer's products use Dinkumware for the C++ library, but I'm not sure what this processor uses. (TMS320C6600 family, if you're curious.) I'm usually at the other end of the pipeline, using the pre-alpha tools before the silicon exists, so I'm pretty far removed from the customer toolchain distribution end of things. Sorry I can't be more helpful on that detail. I can tell you all about VLIW instruction scheduling and cache memory system pipeline behavior though!
Program Intellivision!
That's completely true. But it remains the case that many of C++'s features can be used on those types of devices, and smaller ones too, and that includes templates. Though on programs of the size one tends to find on microcontrollers, there probably isn't much point. You certainly don't want to be dynamically allocating memory, but that's got nothing to do with C++ specifically anyway.
But you're certainly never going to running Java or anything else on those things. It's Assembly, C or C++, and that's it.
This is something I really completely and whole-heartedly agree with.
Related: At a conference earlier this year, a speaker made the point that since hardware speeds are not increasing at the rate they once were, it now makes more sense than ever (and it always made sense) to optimise your code.
Of course, it sounds like the type of optimisation you're talking about is basic algorithm choices and understanding complexity. Which is CompSci 101, but does rather appear to be on the wane. I guess that's a rant for another day.
Before auto it seemed like C++'s error messages were downright passive aggressive: "If you don't know what to put here, I'm not going to tell you." At least, it's not going to tell me the concise thing to put there. It will tell me the completely flattened type, which can be quite huge if you're trying to, say, get an iterator to a nested STL container holding a template class composed against some other classes (that themselves might be templated) a'la the Policy pattern.
I just wish I didn't have to code for the lowest common denominator compiler at work, so I can be sure I can use auto with impunity. :-)
Program Intellivision!
Well, you have to admit that you basically took the worst part of the C++ standard library (the one that even several guys on the Committee think should be killed with fire) for that experiment. It has exceedingly convoluted design, and does not at all follow the "you don't pay for what you don't use" philosophy that's otherwise pervasive in C++.
It may not be verbose to write, but it's still verbose to read.
Its true that a set of 'commonly used' libraries would be easier to handle, and maybe we'd get more contribution and documentation.
But I'm not convinced they should be part of a standard for the language - I like something more responsive to changing needs. Boost works well for this, even if it is full of stuff I don't understand, let along have a use for :)
In the case of most STL generics, they don't default back to a base implementation if the types are slightly different (ie, long versus int). STL containers of pointers should do this, but a lot of compilers don't do this optimization (and many C++ purists will claim that containers should contain objects instead of pointers).
When I work on other peoples code - you know, like in a "job" - then the odds are someone has used pretty much all of the features somewhere in it especially if they're some just out of uni grad who's out to impress his peers and thinks using every obscure language feature and design pattern construct he can find in even the smallest program is the way to do it.
Sorry, but I just can't be fucking arsed with it anymore. A programming language is there to SOLVE a problem, not BECOME the problem.
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 sections that yield the most benefit; go back to #1.
People who try to optimize everything as they go along spend most of their time "optimizing" things that have no perceptible benefit and are far more likely to simply obfuscate the code and introduce bugs. You need to assess need and find out where it matters first. Is it really worth it, for example, to optimize some string comparison that runs maybe five times in your typical program execution? NO. Is such an "optimization" a likely place to find bugs, including potentially serious ones? You betcha.
As a side note, I find most people who obsess over optimization without profiling spend most of their time doing "optimizations" that don't help at all or are often even counterproductive, such as macro bitswap tricks, math-approximation functions, manual loop unrolling, etc, just assuming that they help, rather than things that actually help, found via testing.
When was the last time you ran anywhere? I mean with your own legs, not by pressing 'X'?
So my statement that STL is great if you can afford the overhead is still true. I never said who could or could not afford it. Honestly I say use it if you can. So what is wrong again. Such a simple statement allows for people to decide what it means.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
I use C# in Visual Studio. C++, yes even C++11, looks like a dinosaur in comparison.
Even if I am working on FreeBSD or Linux, C# is better. Mono is easy to install and the MonoDevelop is already friendlier than any other open source IDE out there.
But both Java and C# make C++11 look slow. The syntactical bloat needed to code the same features in C++ compared to C# and Java is just not acceptable.
It isn't just the language that makes C++11 old. It is the fact that IDEs suck. Visual Studio is so far ahead of all other IDEs that everything else is abysmal. However, VS is not as feature rich for C++ so even C++ on Visual Studio is a pain.
#1. Fix syntax. If I were to fix C++, I would change the compiler to support hundreds of the C#/Java syntax. Sure it is syntactical sugar, but that sugar is what makes those languages awesome.
#2. Fix references. Make stupid simple. Check out NuGet and the Java equivalent and implement something. Maybe this is an IDE fix, I don't care. The language is does not stand alone, but the tools around it are important too.
Now for all Langauges, C++, Java, C#, and others. Make the same freaking libraries with the same signatures.
I work in embedded systems. Which means slow processors and not enough ram. So before a project even begins there is a need for optimization. Especially when people on the team were previously windows programmers or electrical engineers.
These are often real time systems, so it is known in advance what parts of the code are critical, and timing is now a requirement and not just something optional. Even in other cases, it is still easier to spend exactly the same amount of time writing efficient code than to write obviously inefficient code, I'm not talking about wasting time that's not necessary and I'm not talking about ridiculously obfuscated C tricks. Ie, even with STL, programmers should know that is it vastly faster to search using a map than a list. You may say that's obvious, but it is not obvious and I have run across people who think even doing that is a premature optimization.
I have sometimes optimized stuff precisely because customers are complaining.
I also write run time libraries sometimes. That is, I write the string library functions. What if all the people who wrote run time libraries thought that optimization was a mere luxury, combined with a programer base that naively assumes all libraries are fast? Often I am going back over library code written by other people and getting huge speedups.
And I do measure the code and determine what it is that is slow and needs improving.
I do get bugs, however the vast majority of my own bugs come from going to quickly and not slowing down and examining all the consequences and corner cases. Ironic since the primary reason to avoid optimization is to speed up the coding process. Most of the time when I am optimizing existing code I am also fixing up many bugs that are also there, as unoptimized code is very often incorrect code.
The STL isn't some big library you link in. It's a collection of templated containers, iterators, and algorithms that can be used individually. Therefore, I don't understand you.
It is possible to create bloat by having, say, vectors of many different classes, but if you are careful with what data types you use I don't see the problem.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
That's one reason why lots of people don't like iostream. It's heavyweight and a pain to write closely formatted text in. For anything memory-limited, I'd go with stdio.h (or cstdio).
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
In my observation (YMMV), most C++ programmers are former C programmers. The assumption is, "If I know C, then I know C++." In practice, they are just compiling C code with a C++ compiler. Once in a while, they throw in a class to club few function. A lot of "systems" companies have such C-turned-C++ programmers who are unaware of the existence of the books like "Effective C++."
Another problem is, many C++ programmers go gung-ho with inheritance as if, in C++, they have the moral obligation to use all the different flavors of inheritance and create a deep (messy) hierarchy without analyzing if such complexity is inherently necessary.
(Long rant truncated)
Yeah, or a custom wrapper therearound is what I end up using in my C++ projects. It's just that early on, there was a lot of "no true Scotsman" argument going around that using directly wasn't in the "spirit of C++", whatever that means.
It's nice to write in and use STL, but if you have to step thru and debug it it's a fscking nightmare.
The third rule is usually quoted as "don't optimise until you've profiled".
But I would add two important rules:
1. If you must optimise something while coding, optimise your internal APIs and your automated tests. That way, when you a performance problem, you can swap code out, swap new code in, and everything should just work.
2. The best time and place to do optimisation is often before you write code, on the back of an envelope.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
So my statement that STL is great if you can afford the overhead is still true.
Seriously, I still don't understand. If you need a priority queue in your program, you need a priority queue. I don't see how the STL implementation of a heap has any more overhead than a by hand implementation.
Such a simple statement allows for people to decide what it means.
Yes, but I want to know what *you* mean by it.
SJW n. One who posts facts.
If the system can afford to STL then you should use STL. Even if you can not use some parts of STL because they are too heavy, use what you can.
I don't see the confusion. STL is great if you can afford the overhead. What part of STL is great do people not understand? If are talking just about PCs then you can probably always use STL. The reason that I say probably is there maybe some off the wall real time application running on a PC somewhere that just cannot use STL for some reason. I would not say always because goodness knows that someplace there is an use case I do not know about.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
But it remains the case that many of C++'s features can be used on those types of devices, and smaller ones too, and that includes templates.
True. And I have done it. I even overrode operator new to allocate out of pre-allocated memory pools. And indeed, the type of stuff you put on such a thing doesn't usually have much need for templates. The one template I did use is a bitmap (as a collection of bools, not bitblt) class, with the number of bits as the only template parameter.
But you're certainly never going to running Java or anything else on those things.
Well, at some point someone thought it was a good idea. But there was the little problem that ARM intentionally has not released all the necessary documentation.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Unfortunately your approach brings one important compatibility issue. It is code - programmer compatibility. When you use STL or other standard library you can bring a new programmer to your project and he would't have much problem to understand the code. But don't use it and the new programmer would have to learn not only your code but your super highly optimized containers too. And I bet that your library wouldn't come with as good documentation as STL.
Taking a page out of badanalogyguy's playbook, I compare it to a hand-built high performance racing car. It's really fast, but when you're driving it close to the edge of its performance it's twitchy as hell and you need a lot of experience to keep it from breaking out and careening off the track. A professional driver can make it do things you didn't even know were possible, and when you try to do the same following a detailed description you spin it out of control time and time again. It doesn't start with an ignition key, you need to flick a bunch of arcane switches in a complicated order to start all the car subsystems. When something goes wrong an unlabeled lights display looking straight out of Space:1999 lights up, and while the errors are described in the huge manual they are still so vague that you only begin to understand the errors after about the 10th time you've seen the same one. And whenever it needs maintenance or extension it turns out that someone manually hammered and bent the standard parts inside to fit, and nothing you can buy fits straight in without adaptation.
But man, it feels great when you run that thing around fast bends doing a great lap time. It doesn't really get you anywhere, but it makes you feel invincible.