Overview: C++ Gets an Overhaul (C++0x)
devx.com
devx.com
Don't get my wrong. C++ obviously has it's place but I'm glad I'm in a different place right now.
I've never seen more then 5% of c code usefully move to asm and I've never seen more then a few % of python code usefully move to a module. I am not saying it's always of waste of time it's just I haven't seen it.
I'm not discounting python inadequacies esp when churning vast amounts of data. Video game levels are large and python was too slow to process collision maps, shadow maps etc but we added C modules to do the heavy work and it wasn't a lot of code to write in C (it was a pita to debug them though).
PS I don't work in video games any more so I've not experienced the delights of the PS3/XBox2 first hand. I do websites now... it's a lot easier :)
Before you chime in with some snarky comment about some superficial aspect of the language (like, say, the name), please try to realize that C++ is still one of the most widely-used languages in the world -- for a reason. And if you find yourself about to post something of the form "why would they add [feature X]...python/ruby/haskell/blub has had that for years", please stop and take a deep breath. Realize that it takes a long time to add features to a language that has to be standardized by committee and deployed to as many platforms as C++ has today.
You may like ruby/python/blub better, but that's a bit like saying "I like my swiss army knife better than my chainsaw". Your swiss army knife will do fine in a lot of different situations, but you're not going to cut down many trees with it. Nor would you try to open a package with a chainsaw.
Some of us appreciate bare-metal systems programming, but loathe C++.
I'm not arguing that C++ isn't widely used. I'm taking exception to the "us and them" sentiment I picked up off your comment, that the world is divided between those who appreciate C++ and those who can't hack it outside of Python and Perl. There are plenty of systems programmers who hate C++.
You seem to be taking this very personally.
Speaking as someone who's spent the last 6 years maintaining large C++ applications, I'd like to think that any C++ bashing I indulged in was at least informed C++ bashing... ;)
The C++ solution would most likely be shorter, more flexible, and more secure. Personally, I fail to understand why anyone would choose to write new C over C++.
How do you suppose memory management works in high-level languages? Magic?
Moreover, the C++ garbage collectors are pretty darned easy to use, given that the language builds in support for custom allocators, overriding new/delete, etc.
If you're using C++ as its own language, you get many of the nice things that come with memory management in dynamic languages, but you don't have to pay for it at runtime (the inclusion of shared_ptr in C++0x is a great example of this, actually). If you merely use C++ as "C with classes" (I'm not saying that you do this...just generally), then you don't see this benefit of the language.
In any case, the reference-counting used by the safe pointers is probably an order of magnitude less heavy than a garbage collector. Even if you use them, you aren't paying that much...
Garbage collection is not an "order of magnitude" more heavy than reference counting, and there's more than one axis to measure memory management on --- in fact, there are several axes for allocation transactions alone.
Just as importantly, if you go to Google Code Search and randomly select ten C++ projects that (a) have more than 10,000 lines of ".cpp" and ".i" file code and (b) use shared_ptr, I'm betting you're going to find that 8 of them rewrote some of the memory allocator for performance reasons. All the fancy template BS in the world doesn't save you from the fact that "new" is just "malloc", and there's no one allocator design that works for every program.
"Avoiding third party deps". The dev team that embraced that standard sure sounds like a blast to work on. The wheel I can't wait to reinvent? Zlib.
Somehow I doubt it.
For what it's worth, pretty much all good C++ devs I know are getting nauseous at any mentioning of Boost .. with "passionate hatred" being a more accurate description. Very professional (older) crowd, responsible for some very notable and large-scale projects.
In general, C++ is too feature-full to ensure any sort of consistency of coding and design styles between any two C++ developers. Some use it as beefed up C, others - strictly as OO language. Former will never be pleased with the code produced by latter, and vice versa. Boost only amplifies these differences, so it's really not a big surprise that it is despised in certain C++ circles.
"Greenspun"
Spoken like someone who has never used a template function.
People choose C over C++ because C is a simpler language than C++, something which this new standard does nothing to address.
That's something I've never found to be the case. Most of my C functions are 5-15 lines long. Anything more than 20 lines long is a candidate for refactoring - the unit tests will tell you if you've broken anything.
If your functions are huge, you should rethink your design, regardless of the language.
http://www.matasano.com/log/914/c-a-cautionary-tale-or-1-hou...
When the working group finalizes the standard, we get to wait for the compiler implementations to catch up. For the first five years, C++ programmers will enjoy buggy, incomplete, and mutually incompatible implementations of half of the features in the new standard. During the following three years, compilers will even out in quality, and many of them will finally implement most of the features in the 2003 modifications of the 1998 standard. It'll take over a decade for C++ lambdas to become semi-portable and acceptable in many environments.
I really hope that, in 2018, I'll be able to write low-level code in a new and cooler language. It'll probably be a Lisp. :)
what you really meant to say is that you hope not to write in any language in 2018
I'm not saying that's a bad thing (or the reverse), and not saying that c# invented these ideas: I'm fairly sure that the c# designers only let in features that have already been road-tested in other, more experimental languages.
Just interesting which was around the ideas are flowing.
C++ isn't going to die, you've got too much code out there, but its place starts to fade away
C++ score = 27.63 Python score = 27.0
PS. Why are the additions of nullptr, and strongly typed enums a good thing? and doesn't C++ already have a NULL from C?
Having a distinct null which can only be arrived at by typing the characters "null" is a good thing, imo.
This was in 1999, I think.
#define NULL __DARWIN_NULL
...
#define __DARWIN_NULL ((void *)0)
int *ptr = NULL; #ifdef __cplusplus
#define __DARWIN_NULL __null
#else /* ! __cplusplus */
#define __DARWIN_NULL ((void *)0)
#endif /* __cplusplus */