C++98/C++03 give no real consideration to multithreaded code, which means that optimizers were free to work on the basis of preserving only single-threaded correctness (and they did!). The only tools you have at your disposal are inline assembly, external function calls acting as natural barriers, and (misusing) volatile. (Or maybe you have compiler-specific builtins, e.g., the GCC __sync_ builtins).
In terms of changes to semantics of pre-C++11 code, the biggest change is that the compiler is no longer able to introduce stores to memory locations that would not have been stored normally. This prohibits the optimization that would change this loop:
for (int i = 0; i < N; i++)
*res += A[i];
into this:
int temp = *res;
for (int i = 0; i < N; i++)
temp += A[i];
*res = temp;
(since res would not have been written if N were 0 or less).
Beyond that, the main effect is that it is now possible to write correct multi-threaded, lock-free code without having to rely on the scattershot nature of volatile. Volatile does not mean what many people take it to mean. The closest approximation to its actual semantics in practice is that any load or store instruction generated from a volatile must not be reordered (with respect only to other such load/store instructions), and it must not be removed (i.e., no dead-store elimination or hoisting outside a loop). In particular, volatile does not prohibit load/store tearing (e.g., reading a 64-bit location via two separate 32-bit loads); it does not prohibit other accesses from being widened to include the volatile memory address.
I know. But I think Java had them before C++, and I think that Java was the first mainstream, C++-syntax, object-oriented language to have them. (Yeah, I know, that's not saying much, because C++ and Java are the only two mainstream, C++-syntax, object-oriented languages.) The point was, C++ could have looked at Java as proof that a language like C++ could have closures, and so one could suspect that the immediate, direct inspiration was from Java.
I only mentioned closures because it's the only feature I could think of that C++ has, but Java had first. (I welcome other examples, if anyone has them.)
C# was the first mainstream language with a C-style syntax to have them - anonymous delegates in C# 2 (2005), then lambdas with type inference in C# 4 (2010).
Java got them in Java 7 in 2011, more or less at the same time as C++11 did.
In any case, Java and C# closures weren't particularly helpful to C++, because they have only shown that a garbage-collected language can have them - the main complexity around closures is wrt memory management and ownership. Hence why C++ closures are very different from either Java or C#.
I suspect that C++ got the now-deprecated exception specifiers - throw() on functions - from Java. But not entirely sure.
I checked my copy of the C++ Programming Language (2nd edition, 1991) which has throw() exception specifiers on functions. The Java project started in 1991.
I'm not sure these qualify as closures. But if they do, then they've been around in that exact form (named local functions with language semantics preventing them from outliving their environment) since Algol-60.
> I have no idea what the c++ committee were using as predicates
And in fairness, neither do I. My point wasn't "C++ copied closures from Java". My point was "I can't think of anything else they copied from Java", and therefore that I suspected that the answer to jedberg's question was no.
