That's true, at least to some extent - but it is also true of C. At most, it is a matter of degrees and that such things are perhaps more pronounced with C++ than C.
Consider this pseudo code in C:
extern int part1, part2; extern volatile bool GIE; // cpu's "global interrupt enable" flag
void atomicSet(int a, b) { GIE = false; // Block all interrupts // Set both parts as an uninterruptable operation part1 = a; part2 = b; GIE = true; // Enable interrupts again }
A great many people would think this is correct code. On a great many compilers, it will do as the programmer expects. But on some compilers, with some optimisation flags, it will /not/ work. This is because the compiler can freely move the stores to part1 and part2 with respect to the GIE assignments.
I can well agree that such issues can be surprising, and lead to hard-to-spot bugs. And I can well agree that you are more likely to see such bugs with more optimising compilers (or compiler flags). But I can't agree that C++ is so very much more prone to this than C, nor can I agree with avoiding optimisation in the hope of avoiding such bugs. (The compiler is free to make the same movements when optimisation is disabled.)
How do you handle this with C programming? (That's not entirely a rhetorical question - if you've got a good, non-obvious answer, it would be nice to hear it.) You do the same thing with C++.
That's true - but it is also true of C. Take a look at comp.lang.c - there are people there that have studied the C standards for decades (and sometimes been involved in creating them), and they /still/ argue over details and interpretations.
So I agree with you - I just don't think it is a good enough reason to avoid C++.
Well, a lot of people seem to make a living out of programming in C++, and a lot of software written in C++ seems to run reasonably well.
But I think it takes more work and greater ability to be a /good/ C++ programmer than to be a good C programmer - a lot of these C++ programs will have subtle bugs, and a lot of the developers will not be good enough to understand them.
Just like with C programming, many of the potential bugs in C++ code can be avoided by using a limited subset of the language. If you think member resolution for class hierarchies with multiple inheritance is a likely source of subtle problems (and it is!), then ban multiple inheritance - you have very little to lose, and a lot to gain. It is just like avoiding malloc/free (or new/delete) makes your code immune to heap memory leaks.
(I am not trying to say that this is an easy thing to do, naturally. I am not even trying to say that C++ is a good choice for any particular usage - I am just saying that some of the arguments given against C++ are not valid, IMHO.)
For gcc 4.5, I am saying "partly yes" - it had a fair number of C++11 features that are useful. Some of these were considered "experimental"
- meaning that the gcc developers think they work correctly, but they haven't yet had the wide testing you can only get by releasing the tool for general use.
For gcc 4.7, I am saying "yes", and for gcc 4.8 "YES".
Maybe I misunderstood you - when you said "that the vast majority of people regard as complete", I took it to mean that people can use C++11 features for normal usage, rather than requiring absolutely every little nuance of the standard to be fully implemented. If you look at the cxx0x status page I gave, you will see there is only one item that is /not/ implemented ("Minimal support for garbage collection and reachability-based leak detection"). If you want to be black-and-white, then gcc is not C++11 complete. If you want to be practical for "the vast majority of people", then yes, it is complete.
(I can't comment on whether the list on that page covers every aspect of C++11.)
The gcc C++ library is perhaps not as C++11 complete, according to its status page - though I think that page is a little out of data (the big missing feature is regular expressions, and these are at least supported in the development version of the library). But I haven't looked much at the C++ library.
It is a matter of what is meant be "complete". As noted above, it seems we have a different idea of "complete", and I misunderstood what you meant by it. In the black-and-white sense, then gcc is not C++11 complete. (And by your reasoning above, probably no compiler can be "complete" to any C or C++ standard - not even ANSI C or C89.) But in the practical "can I use this tool to write C++ code using C++11 features" sense, then gcc was roughly complete in 4.7 with a few final additions in 4.8.