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).
The Sooner the Better!
Java Ruelz!
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?
The concept of a standard library is just baffling.
You shouldn't teach STL anymore. The world has moved on to the C++ Standard Library and so should you.
If you can afford the overhead, you can afford easier languages.
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
If I recall correctly, many major developers for the previous generation of game consoles used custom STL implementations because the overhead was too expensive otherwise. Not that the PS3/XBox360 were anything special, but they're not slouches either.
Example: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
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.
I think the STL is amazing, and I'm glad that it's a standard part of C++, but in my experience, it's usually far too general purpose to wind up in production code. This flexibility comes at a performance cost that, however modest it may be, can often simply not be worth the hassle of maintaining. I may use the STL during prototyping, or when first implementing an algorithm in code, but will often incrementally move to using custom types as a project develops.
File under 'M' for 'Manic ranting'
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?
USA Independence Day 2014
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...
As someone who is coming from learning C#, Java, and C++ as a student, then going on to use C++ in my first programming job ( 6 months so far), it is syntactically clunky, inflexible, debugging it is a chore and if you fuck up, you fuck up big time. Performance gains are negligible at this point, though I'm sure there is a lot of room for improvement.
Hi there, have you been contributing to OpenSSL?
"They are always curious about what practitioners are doing these days." Those who can DO, those who can't TEACH. Get out and do some damned consulting, keep up on your industry, get your head out of your tenure and get into a job that makes you feed yourself on your skill in the field. Once you do that, then you have something valuable to teach. Other than that, you are just regurgitating someone else's opinions on things. Get some experience and make your lessons valuable to your students. By the way, I adjunct teach and my students ask the same things. I can actually answer them intelligently. I can give them a real-world example of the how's and why's of what I am teaching them in. With any guaranteed job, you stagnate in your knowledge to what is on the resume you were hired with. Tenure is the problem.
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 never cared much for STL. I don't find it all that useful. But I grew up learning programming thru assembly language and later plain-old C, so I'm biased towards keeping the languages at their core without the window dressing. There just isn't anything in STL that I can't replicate quickly using basic C/C++. It avoids a lot of compatibility/portability issues as well.
When all else fails, run.
... the more I like other programming languages.
I'm sorry but all this "everything can be solved with a few more templates" mindset plus the feature creep remind me of only one thing: cancer.
I apologize for the lack of a signature.
I actually took Stroustrup's advice and relearned C++11 as a programming tool in it's own right rather than just C with more features, and I've become much more productive, my code is smaller, faster, and more demonstrably robust, and life is generally easier, except for the part where I sometimes work with people who do not. C++11 and beyond make me happy; I like using them, and I no longer worry about the future relevance of the skills I'm using now.
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"
Overhead compared to what ? Not doing things at all ?
Can you point to an example of how your container is more performant than the STL?
And why is that? Why give up references and other useful C++ improvements just because you aren't going to use 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)
Could you be referring to this?
The few experiments I've tried with STL have been a bit too heavy and slow - at least with my uses which are frequently not single threaded.
My last test ran faster in python.
so I'll stick with C. Good old efficient, manageable and predictable C.
However I hear the STL is great for many people.
I have been working with C++ (as well as Java, C# and other languages) for several projects over the past 13 years. Since C++ is still the main language for the projects I'm paid to work on, I find the improvements to the STL useful every day in avoiding doing custom things. We used to have our own class similar to std::shared_ptr and std::unique_ptr, which we have since replaced with the standard. With std::bind() we have reduced the complexity of many of our functions. As another commenter said, the 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.
Now you really have to think about this one, but ...
By introducing "auto" for types, C++ has admitted that it is too complex for human beings to understand. The "auto" type declaration means that only the compiler can figure out what to put for a new type. By using it, the programmer is saying "I have no idea what to put here, so I implicitly trust the compiler to do it for me."
This is similar to the IDE. Something like C# or Objective-C is so complex that it is collapsing under its own weight, so the solution is to give programmers an IDE that hides the broken mess of ad-hockery from the programmer. By giving programmers Xcode or Visual Studio, a company is admitting that their development tools are so complex that they can't understand or fix them. All they can do is put a band-aid over them in the form of an IDE.
The introduction of these crutches shows programming is getting too complex for human beings to understand.
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.
especially C
-=/\- Jizzbug -/\=-
C99 pulls many of the non-object usefull C++ improvements in like references.
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).
We're still doing all of the inner loop stuff in C so that timing is deterministic. STL being a little slower (it is) isn't the problem for us; it's that it's not really consistent enough for life safety critical systems. Oh, and we can't use it at all without a virtual memory machine.
I was going to say the same thing. At my last place of work there were always "hotshot" developers writing "blazingly" fast and needlessly complicated code. I never once found a case where elegant use of C++11 couldn't compress the same behavior to 10% LOC, outperform their code and fix a few bugs in the process.
The moral of the story; If you can use STL, use it. Ideally in the most simple, readable and straightforward way you can. If code is simple enough to understand at a glance and the underlying algorithms aren't bone headed, it's probably about as fast as it gets.
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.
The question is often what you consider "overhead." Which in the embedded world is often memory, not speed.
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.)
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.
So have they finally fixed the name mangling issue, calling conventions, and binary compatibility with C++ libraries produced on different compilers for the same architecture? No?
Carry on then. Nothing to see here. I'll just continue using Java and C#. If I try to link a library there, it Just Works(TM).
I haven't seen performance problems with the STL in years. I write low level mathematical solvers for CAD/CAM systems and I use the STL all the time. I never have performance issues with it.
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.
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.
Most modern languages offer managed execution, while C++ doesn't. Sure, everyone can name a few situations where unmanaged code is still needed, but the 98% case in modern times is for managed code. In fact, many programming shops won't allow the use of unmanaged languages to develop customer-facing apps any longer, due to the risks it entails.
C++ needs this as an option unless it wants to become increasingly irrelevant to modern programming. Already they just teach Java or C# in many CS departments now, not C or C++.
Change with the times, or go the way of the buggy whip industry.
No, I use MSVC++ .NET express. I don't think Microsoft Visual C++ comes with the Standard Template Library, but I might be wrong.
I write image analysis software that has to interface with cameras and other devices through USB, Firewire, Ethernet, and serial connections, and which processes 4 GB of images per minute, using a variety of filters and segmentation algorithms running in different threads to make different measurements in parallel. Getting the code to run fast enough was mostly a matter of clever algorithms, but SSE vectorization (some done manually, some done automatically by g++) is also necessary. And, because I'm doing my own memory management instead of using garbage collection, the program only needs a couple hundred MB of memory, total, to handle that stream of 4 GB per minute. It was also helpful that well-tested C libraries for all those communications interfaces were available for free. So, in terms of C++ vs. something like Java, C++ is still the best option in my particular field.
As for C++11, it's only been in the past year or so that g++ fully supported it, so I haven't begun using it at work (although I do use it for hobby projects at home). Some features like nullptr, emplace_back(), range-based for, "override" and "final," and the "= default" and "= delete" syntax are very useful and will help people write less buggy code. Some other features, like being able to correctly parse "vector<vector<int>>" without a space between the closing angle brackets, are way overdue, as are some minor things like supporting a string object instead of a char * as an input to ifstream::open().
Other features, like lambdas, delegating constructors, and some of the klunky new libraries, I'm not sold on, yet. And for most situations, "auto" seems like a very bad idea; it makes code easier to write but harder to understand. And the new "->" function definition syntax, although I understand why some situations require it, feels rather ugly to me.
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.
I can get things done with it which were a complete pain before STL started to work w/o too much thought.
I don't write Perl scripts any longer. But, I never really try to use things like exception handling, inheritance, multiple or otherwise (unless seriously shallow), non-trivial const correctness, operator overloading, etc. There are weeds in there you're not likely to recover from brushing against.
Long story short: now great for simple, "get it done" jobs which were sending me to scripts before. If I were writing a modern library (e.g. Qt or the like) I'd stay way away from it.
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.
C99 does NOT have references.
A *lot* of these comments reflect dated impressions of C++. Try this, which gives a great overview of what C++ can be when you're using idioms from C++11 (and it previews some of C++14).
http://channel9.msdn.com/Events/Build/2014/2-661
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.
There are no references in c99. It is filled with lots of other useful stuff though.
Primarily, you get bools, vlas, variadic macros, restricted pointers, designated initializers, complex numbers, ability to declare variable where they are used instead of the function header and the ability to bind array lengths to array arguments to a function.
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.
I love reading the comments by sub-par programmers whining about C++. Stick to your toy languages (Java, C#, Ruby, Python, etl al.), and you'll be OK.
No need to "trust" the compiler. The compiler is at all times 100% aware and sure which type a certain expression will yield. And since it knows anyway its often convenient to ask it to supply the correct type. So its more "Dont make my me type so much" than "I have no idea what to put here". But surely some people will use it that way as well. It also could save you a lot of time when you choose to change containers for example.
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.
Then you're just a bad programmer. I write real-time embedded systems with C++ and the STL. STL blows the doors off your roll-your-own crap. Good old efficient, manageable and predictable C++ (hey, if you can write sentence fragments, so can I). STL *is* great for many people (people that actually know how to write software).
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.
still bad, getting worse with time.
Features are added and behavior is changed for the sake of changing, with no benefits to any software quality whatsoever.
C89 is still the only language which makes sort of sense to use for low-level programming (with most of the c99 and later standards adding nothing of real value). For higher level programming, there are much better languages to use.
A niche for a _subset_ of C++ is in graphics and games programming, since those applications really profit from the balance of performance and object-orientation of the language.
I have to use C++ in its latest incarnations on the job every single day, and it's just terrible.
Thanks for asking and for a nice opportunity to vent in frustration.
"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".
plus the "advantage" of not having any idea about what that type might be by just looking at that fragment of code if the variable is assigned a result from a function call for example.
And the "feature" of having a good fun run through the code to find out what that type is.
But of course all of that is fast and easy because we professionals all use...
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.
an IDE! Yes of course, who wouldn't?
And of course C# is equal to C++.
Bravo for the top trolling.
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."
Agree. When I complained about C++ complexity to a friend of mine, who knows Bjarne Stroustrup personally, he said "Bjarne did not do it deliberately. He is a nice guy."
Just today, when another friend of mine mentioned he wanted his son to learn a bit of programming by starting with C++, I told him that is the surest way to turn him off coding forever.
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.
> Things like HTTP, XML, web services, SQL, configuration, and cryptography should be built in
I couldn't disagree more.
C++'s standard library follows the same general philosophy as C's. The standard library is for features which earlier languages typically made part of the language, but don't actually need to be part of the language.
E.g. Fortran, Cobol, and Basic all provided I/O statements (WRITE, DISPLAY, PRINT), with their own keywords and syntax. C provided library functions, declared in stdio.h.
High-level languages have to throw everything (up to and including the kitchen sink) into the standard library, because you can't just use any old third-party DLL/DSO directly from within the language; someone has to write a shipload of interfacing code (JNI or whatever) first.
The problem with trying to standardise high-level functionality such as HTTP is that the interface either has to accept a thousand parameters to control all of the myriad details, or it has to make a thousand choices for you (and many of those will be the wrong choice for some non-trivial proportion of its target audience).
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.
I have done a lot of
Java, some what significant C++ and a lot of other languages. Scala is the way to go. C/C++ only for compute intensive and/or High Performance Computing. Everything else that is more complex and not compute intensive you are better off with Scala (compatible with Java and yet much more elegant and concise).
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.
Many of you consider C++ to be an abomination.
Perhaps this list might change your oppinion a bit:
http://www.stroustrup.com/applications.html
C++ is the way it is by *design*. It is ment to solve really well a *subset* of problems, not all problems. Some of the critics here remind me of people who go watch a comedy in cinema, and afterwards criticise it for not being a drama.
screw you im still using ada
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
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.
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.
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.
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.
The move semantics make me laugh every time I think of them. They introduced another potentially vexing parse in order to overcome a situation where extraneous copies of things are generated to return something from a function. How many of you were taught in programming lectures that this occurred? (Answer: None, you were too busy struggling with circular inclusions to even begin to grasp the shittiness of the underlying language).
They didn't admit that the spec was fucked and even at the C++11 talk Bjorn rants about how performant C++ is. In fact for him now all he wants to do is play with mangling the syntax for specific purposes. He STILL is not a fucking programmer, he's just a fucking wanker.
So they put this all through the new STL. Did they admit that all those years when they said C++ and STL was faster, that they were wrong? Did they give us an estimate of how many TRILLIONS of CPU cycles were wasted worldwide because of their failure? No, they gave themselves a pat on the fucking back.
The only thing you can say about new C++ is that someone should have started designing a proper replacement 20 years ago. And in 20 years we will look at C++34 and the new STL and think the same thing.
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++.
I used C++ for about 15 years in the video games industry and real-time engineering applications. More recently, I have been using C#, because now I mainly write Windows applications with a lot of UI. I wouldn't change either of these facts; each language is suited to what I use it for, and I am not sure I could settle on either one as my Swiss army knife.
That said, I take the earlier point that modern languages (like C#) often seem to have a horrendous number of classes involved in everything. Virtual classes abound. and you can't find anything concrete anywhere, particularly when you start drilling into code with the debugger, and everything is a collection containing more collections.
I'm perhaps stating the obvious, but it seems to me that complexity cannot be avoided. You either choose to express is in code (C++) or in architecture (C# and co.). Both approaches are hard. But if they weren't then everyone in the world would be able to write software, and we would all be out of a job.
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.
I've been a freelancer for 14 years now. In all that time C++ (and C for embedded) have always been my languages of choice. After all that time I've become fluent enough that the only hard part is good system design, and that is fairly language agnostic. STL makes life very easy. Using QT for developing applications makes it ridiculously quick to write user interface apps that can compile on Windows, MAC or Linux. You can get a simple app up in presentable form within a day (at a push!) and that's without using "QT designer" (QT layout containers make it very easy).
Yes C and C++ has a steep learning curve, and yes it lets you do stupid things but that freedom also lets you do clever things. Once you know what you are doing and follow good practice, it is *easy* and becomes second nature. And no dealing with pointers is not hard. You can use selectively use smart pointers if you really want to (works especially well for apps based around asynchronous I/O, which most of mine are as I mostly deal with client/server systems).
Regarding Java. Whenever I use a Java app it feels a bit sluggish. Just my experience; it could well be I've never used a great Java app. I feel a little "constrained" too when I write in Java, but it could just be I'm not used to it.
Having said that, I think there is too much stock put into programming languages; they are a means to an end. A good programmer with a good design is what matters.
this paper is a little old, but many of the motivations are still sound:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#Motivation
there still quite a few game development houses which ( for similar reasons ) either roll their own versions, or completely avoid the stl altogether.
personally, i think what matters most is: good documentation, reliability, and testability. all of which the stl is very good at.
most of the time, when programmers are hyper-obsessed on the footprint of vector::push_back() or the speed of hash_map::find(), they seem to miss questions like: do we need to call that code at all?
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.
Works as intened, predictable, well documented.
In many environments where I was responsible for there was a simple solution for all those different Ruby Gems, as well as different (incompatible) Java libraries: NOTHING, but really NOTHING gets installed on the system, everything is installed in a self contained root folder (i.e. /opt/) and when I do a system upgrade, and your ruby code breaks, its up to you to fix the project folder. Of course that was tested up front in QA and UAT. Most rollouts of new code are then tar ball drops into the respective folders.
Even vendors if they write commercial corse can be made to play with those rules. Most seem already to be aware that there are a good number of sysadmin folks out there that look at you as if you are crazy if you want to install anything within the system folders.
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.
I've been a heavy user of C since 1986, C++ since 1990.
First, there are a lot of comments here disparaging C++ in favor of something else, Those things are nice, they're fine, most of them would not have come about if not for the C lineage, which has been shaping OUR minds for what 40 years now? I was compiling the gcc stack back in 1992 and it was the most amazing toolchain I'd ever seen at that time, let alone what it is capable of now. The modern compiler solves a lot of the chronic problems (unchecked printf varargs) that were the most error prone (and led to things like "streams"). As for those who have trouble with naked pointers,
C++ stalled for a while before STL in competition with the OO languages of those days and because we had simply not grokked the utility of generic programming. I have to say that C was still my choice before the STL. C++ would probably have languished had the STL not happened. Anyone who doesn't appreciate STL has never had to debug and unify 14 enterprise-wide C implementations of Linked List to solve a memory leak or add threading to a mission critical high performance application. (yeah, STL containers not thread-safe... but if you use them for what they are and add scoped locking, you'd be surprised! )
C++ is for C++ programmers. STL is for C++ applications programmers.
C++ is for C++ programmers and that includes anyone who needs speed and efficiency for a highly complex problem, learn your pointers, learn your heap management or else use shared_ptr (thank you STL + C++11!) and deal with what comes with that. Unless we're all going to port all our complex systems to D or Nimrod, or a handful of other advanced bare-metal languages, then write and publish workarounds, stop arguing against C++, and keep lobbying. It's NOT GOING AWAY no matter how painful it might be to understand, read or write. The codebase includes most of the usable operating systems, compilers, database, and commercial as well as Open applications,
There are 3 HUGE reasons for that:
1.) It deals "well enough" with complexity, with a price of requiring a mind that does also. (C does fine, but it's a lot of writing)
2.) It does not have a VM layer, Interpreter, JIT, or GC to complicate and distract from the task at hand and add (noise, errors, and compatibility issues)
3.) What do you have? It can work with that. (a purple paisley Intergalactic people eater?, yep, just write the interface. )
In all those years working with C and C++ my C++ knowledge by the online "tests" still doesn't get past 90%, mostly because the tests cover a lot of corner cases that I have no reason to bother with, (i.e. I'd never write that, it's stupid.) Most of what I do now is maintenance, re-factoring and re-engineering, I'm re-factoring a lot of code that looks like what we used to write in the 90's, in fact it was written in the 90's. In most cases each application contained it's own entire infrastructure layer to deal with interrupt-based I/O, polling directories, reading pipes, shared memory, etc. Organizations I've seen and worked in have had stale, wasteful, flawed and awkward implementations of all those things that MOST applications HAVE TO DO for so long now. There's never time or budget to re-work until something is banging up against the far right edge of the bathtub curve. BUT!!!!! When you DO get to revisit some of these old applications with the STL in your hands, you can tear out huge swathes of unmanageable legacy code. Replace a dozen on-the-fly linked-lists with a vector, deque or whatever actually makes SENSE to use in that case! Replace hundreds of looped in-line tests with lambdas or even with C++98 functors!, add threads that are READABLE, with locking that's not painful!, IO queues that reduce contention! A whole reusable application infrastructure assembled from customized objects! when you're done you NEVER have to deal with one more awkwardly unmanageable C Object again (in THAT codebase anyway, but there are so many more waiting)
C++ and STL is getting much better ea
That's not the c++ the language's fault, that's C++ libraries. The concurrency stuff is a library, it's not yet baked into the language. The async library was a failed experiment. Better things will come. If it was in the language, we'd have a problem. When it does arrive in the language, if, it'll be better.
C++ is getting better. Any non toy language will evolve the same warts as C++. Look at the size of C# now, another great language, but C# took out some good stuff from C++ and didn't replace it with anything better. Making C# at best arguably as good as C++, but without the same code base even it's user base is good, and at worst, C# is well, worse.
STL is at times hard to use but Concepts will make it *a lot* easier to use. They don't throw stuff away every week like MS do. Even large companies can't afford that attitude.
Concepts will pave the way for STL to perhaps get augmented with another STL. But that won't happen until it's leaps and bounds better than the existing STL and in the mean time the current STL will become concept based itself and that will improve what we have whilst preparing the ground for something drastically better. But steady evolution is better than boom and bust of new stuff if you're serious about long term projects.
None of this is to fault C# in particular or any other language or to say C++/STL isn't without it's faults. It's to say that any non toy language goes the way C++ does. Just a lot of other languages get dropped on their head as soon as their main corporate backers loose interest. C++ does have a real community behind it. Time will tell, but C++ has been around a long time and I don't see it going away, and I do see a lot of practical evolution occurring without throwing everything away each time.
Can I say I love using C++ whilst totally agreeing with you. I'm not sure what that means except playing with grenades is fun perhaps. I switched to C# a long time ago and switched back to C++ recently. Life was productive in C#, but far too boring!
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.
A million lines of code in 10 years would be childs play if you're a real pro.
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; }
I will definitely try it out! iDroidSpace
The STL is very useful and incredibly fast and has gotten faster due to the new move operator semantics made available in C++11/C++14. At our institution, we use a search application that needs to do custom searches and retrieve results quickly. The application was at first written in java and a typical search took about twenty minutes. It was rewritten using C++11 specially taking advantage of the move semantics and the search times went down from twenty minutes to 3 or 4 seconds.