But ultimately, as long as it lacks memory safety, it lives in a mostly parallel universe from Java and everything else. It's not really becoming more Java-like. It's becoming more C++-like. C++0x goes in the direction of having better support for existing C++ idioms.
I don't get your point. If A lives in a parallel universe from B, then B lives in a parallel universe from A.
I think what the grandparent wanted to say is that memory management is a defining difference between the paradigms of both languages. There are some people who value the fact that they have full control over allocation and de-allocation and others who think that these are things the programmer shouldn't (have to) care about, because they're known to be error prone.
The original parent said "Java and everything else", leaving an implication that unmanaged memory stuff was marginal. I think that's what the gp is addressing.
I've always imagined Herb Sutter as a Gandalf-like figure and here he is looking like a partner in a New York law firm. I guess it is possible to achieve guru status without a beard.
I can't wait to get support for the "auto" keyword in XCode.
Interestingly, C++ was ratified as an ISO standard just as Java failed to get ISO pick-up after a campaign by Sun
Actually, even more interestingly, Java failed to become an ISO standard because Sun didn't want it (at the time they were worried about the potential influence of Microsoft).
I have a lot of respect for Herb Sutter--his articles on difficulty of multiprogramming are worth study by all. But there is an element of Kool-aid in his comments about other languages. Hadoop is written in Java; much of the world is written in C, and in very restricted versions of C++. I say this as one who did 10 years in industrial-strength C++ programming.
If you look at C++ without rose-colored glasses, it is a pretty frightening prospect. Modern C++ Design by Andrei Alexandrescu is a very awesome book, but the fact that there are surprises in it for Scott Meyers should give the student pause.
And to all of you who are beginning programming, you will be better off in the long run if you become proficient in several languages. I predict that in your successful career you will be ahead if you are able to pick up new languages rapidly. Time spent mastering C++ might not be the best use of your learning budget.
"... the Apache MapReduce clustered data-processing architecture ..." I'm not very familiar with internals of Hadoop - but thought this was mostly Java.
Here's a list of what seem to me, in hindsight, to be the biggest mistakes in the design of C++:
1) Header files. They don't improve your code or your build process in any way, they just make you retype everything twice and make the compiler reprocess everything as many times as it's included. There's no reason why even a low-level language today can't have a module system like Java's, where everything is typed in and compiled only once.
2) Having exceptions without having garbage collection. Having both of these, or none of these, would have been OK, but having one and not the other makes writing exception-safe code unnecessarily difficult. It took people years to write the first correct exception-safe container class and understand all the tricky leaks that can happen. See Tom Cargill's 1994 article: http://ptgmedia.pearsoncmg.com/imprint_downloads/informit/aw... and Herb Sutter's failed answer in 1997: http://www.gotw.ca/gotw/008.htm .
3) The template mechanism is too general and not a good fit for many of the tasks that people are trying to solve with it. Easy tasks like parameterized container types would've been better solved with a simpler mechanism like Ada generics (no specialization, no implicit instantiation, only one copy of object code, possible to compile separately). Harder tasks should be solved with purpose-built mechanisms, e.g. if you really need lambda, build it into the language. Faking lambda with templates isn't much better than faking it with preprocessor macros.
4) Strings should've been built in, and done right. There must be only one string type (Unicode). All string literals must be instances of that type. No null-terminated strings anywhere, they're a very bad default. If your application demands shaving a couple cycles from operations on character buffers, you can always use custom code.
I'm not asking for garbage collection, multithreading, GUI toolkits or any other fancy features. C++ could've gotten these five things right and still be a very good fit for all the bare metal speed hackery that people want.
Not that I am a C++ fanboy, but your list is sort of orthogonal to what I would list.
1) Header files. They don't improve your code or your build process in any way
They improve modularity. I have a header for each module which list the functionality exposed from that module and nothing else.
This avoids leaking implementation details, helper functions, etc. and it allows me to “ship” the module in binary form (a static or dynamic library).
2) Having exceptions without having garbage collection.
As for your example of container classes, the problem (IIRC) is to not leave the container in an invalid state, when the exception is thrown, e.g. if you insert a range into a vector, and an exception occurs in the middle of this, you need to rollback before rethrowing the exception.
Relying on the rules of when objects with automatic storage are destructed actually makes this easier than not having automatic storage (but instead a garbage collected heap with non-deterministic behavior).
3) The template mechanism is too general and not a good fit for many of the tasks that people are trying to solve with it
The C++ template mechanisms gave us STL, something the author said no other language allowed him to create, and something I am truly grateful for having been exposed to in my career.
While I don’t particularly like many of the uses of templates in boost, i.e. the template expressions you refer to (like faking lambda functions) I don’t consider it a mistake to have introduced a flexible compile-time macro system. I mean, everything can be misused…
4) Strings should've been built in, and done right
Strings weren’t really “designed”, many compiler vendors did their own string classes, and the standard tried to adopt sort of a common denominator (I mention this since your list is issues with the C++ design).
As for having to be built in: I don’t think types beyond the most primitive stuff needs to be built in, but the language should allow the user (library supplier) to introduce new types that look and feel exactly like built in types, that way, we can also get regexps, matrixes, associative arrays, sets, a.s.o. as types which feel like first class citizens.
> [Header files] improve modularity. I have a header for each module which list the functionality exposed from that module and nothing else.
Have you seen how Java does it? You annotate your stuff as "public" when you want to expose it.
> As for your example of container classes, the problem (IIRC) is to not leave the container in an invalid state, when the exception is thrown, e.g. if you insert a range into a vector, and an exception occurs in the middle of this, you need to rollback before rethrowing the exception.
There are two problems: leaving the container in a valid state, and avoiding memory leaks. The former is a problem in most languages with parameterized types and exceptions. The latter is a problem only in C++, because what you call "automatic storage" makes exception-safety difficult as I pointed out. Since adding garbage collection to C++ is still a non-starter, I'm gonna go ahead and say adding exceptions was a mistake. The C way with error codes was better. With error codes, writing an error-safe Stack class would've been a task for one day instead of three years. (Granted, the code would've been longer and less "subtle". I don't care.)
> The C++ template mechanisms gave us STL, something the author said no other language allowed him to create, and something I am truly grateful for having been exposed to in my career.
I'm not sure the STL should ever have been made an industrial standard. People mostly need things like foreach, filter, fold, find, sort... STL's interface for such operations is too convoluted, you have to write a lot of weird code that doesn't do anything except make the compiler happy, learn about iterators etc. The sweet-spot interface (IMO) is by using closures, like Smalltalk does it:
> As for having to be built in: I don’t think types beyond the most primitive stuff needs to be built in
Well, you can't help having strings built in, because the language has string literals, right? They must evaluate to something. All I'm saying is that the wrong default (making them evaluate to a pointer that points to the start of a null-terminated string, and having tons of library functions that accept those) is worse than the right default (making them evaluate to an instance of a built-in string type).
> the language should allow the user (library supplier) to introduce new types that look and feel exactly like built in types, that way, we can also get regexps, matrixes, associative arrays, sets, a.s.o. as types which feel like first class citizens.
This generally doesn't work unless your language is extremely syntactically malleable, like Lisp, and I'm not sure it's an especially worthwhile goal. Can C++ get regexp literals like in Perl? Map literals like in Javascript? Actually it doesn't even have array literals, instead it has "initializers" that aren't even rvalues. I think the sane decision is to give the user a bunch of built-in types that cover like 80% of the required functionality (booleans, numbers, strings, arrays, closures, maybe also regexps and maps) and let them implement the rest as libraries without worrying that their new type "looks just like a built-in".
First, it's a bit late to bolt this on to the language now that mountains and mountains of libraries and applications have been written to use manual memory management.
Second, a lot of people use C++ because they need low-level control of memory use and can't tolerate GC pauses. If you're writing the kind of app in which GC is acceptable why not use Java or an even higher level language like Scala instead?
Left out, which IMHO is a good thing. The C++ language as it stands right now, especially with the C++0x additions has provided plenty of new features that are going to help developers build amazing software with more power.
Not everyone wants or needs garbage collection and it would be a downright pain to bolt it on now.
Feel free to use one of the umpteen other programming languages that does provide garbage collection, clearly if you are complaining about that you are simply using the wrong tool for the job.
It's rather harder to count the number of times there were idioms you could have used but didn't because using them in C++ wouldn't have been practical or efficient. I'm thinking in particular of closures which captured state, and functional/monadic style chained method calls each building on the previous function's return value (think: something like .NET LINQ).
It sounds like you're referring to C++98 while the article specifically talks about C++0x. C++0x adds closures to the mix so it's now very possible to implement something similar to .NET LINQ in C++.
No, I'm not; I explicitly mentioned closures which capture state precisely because that's where C++0x gets thorny. You can capture by copying or by reference; what you don't get is wholesale movement of the variable into a heap-allocated location, the way variable capture works in almost every other language supporting free mutation of variables.
My bad, I wasn't familiar with the term. I'm still not convinced this is a limitation though. If you want to modify an object, passing by reference usually makes perfect sense. For those occasion when this is not the case, you probably already have a smart pointer in your hand, capture it by copy. A counter example would be great.
BTW the behavior you describe has been achieved in the C language family with Apple's C block extension, not that it's relevant since it's in no way standard (aside from Objective-C++)
C++0x introduces a bunch of smart pointers to the standard library (and boost provides them externally for previous versions). What are the advantages of garbage collection over these?
The mere fact that you have to use smart pointerS is enough of a drawback; not only do you need to start decorating various types explicitly, but you must choose which smart pointer types are appropriate, and avoid issues of circular references (in the case of refcounting) and persistence of references (in the case of scope-guarded objects tied to a stack frame); worry about logical ownership hand-off from one smart pointer container to another, etc.
The real power of GC, though, is freedom to use idioms that are simply impractical, or especially, not exception safe, in its absence (see my comment earlier).
If you really want to dive straight into the deep end, I'd recommend Modern C++ Design by Andrei Alexandrescu. But if you want just a gentle introduction to C++ I'd suggest The C++ Programming Language by Bjarne Stroustrup.
Both of these authors are staples in the C++ world and so their advice is usually worth their weight in gold.
But ultimately, as long as it lacks memory safety, it lives in a mostly parallel universe from Java and everything else. It's not really becoming more Java-like. It's becoming more C++-like. C++0x goes in the direction of having better support for existing C++ idioms.