Sure, but you'll need a time machine

Fortran doesn't have pointer aliasing. This allows the compiler to perform more aggressive optimizations

Of course, the STL was written by Stepanov before C++ was standardized. What the interviewer probably meant to ask about is the C++ standard library, which is similar but different. Or maybe they really were asking about the STL, in which case I wholeheartedly agree that bullets were dodged.

Wasteland 2 comes out this Friday (9/19) and Pillars of Eternity is still in Beta. Unless you've got a time machine that's about as new as it gets.

If only, Los Angeles has a vanishingly small subway system. One subway line that goes from downtown LA to North Hollywood, and an aborted line that was meant to go to Santa Monica but only made it to Wilshire.

Except that the original question only specified the parameter to be an integer, not whether it was signed or not (nor what range of values it could take)

lambdas can be faster than say, function pointers, mostly because the compiler can have more information about pointer aliasing. They should be a wash speed-wise relative to loops. Also, you say functors, which can take a few forms; this can be a callable object (e.g. a struct with its operator() overloaded, no templates needed), a stored lambda function, or a std::function object (e.g. as created through std::bind, lambdas, etc). They all look rather different; do you find all of them unreadable? Not all of them require 'enormous' header files

It was stated in a different article that they were unable to procure the current ones used in airports (millimeter wave), and that it was already rather difficult for them to acquire this one -- perhaps now you know why

Well apparently not, because you stated multiple points that are, as of today, patently false. Perhaps it was different in C++98, but (in case you didn't know), it's not 1998 anymore.

Not as many as possible. Use the right tool for the right job, as always. But don't rule out libraries because they use templates -- that's downright silly. Templates are made for writing generic code, which maps very well to libraries. Lastly, I don't claim to be a *good* programmer, but I do at least make an effort to understand the language that I'm using.

Might I ask what you feel to be unpleasant about C++11's additions? Do you have any specific cases in mind?

A lot of people will (and do) use the =delete syntax. Prior to that you would have to declare the method as being private, but this wasn't perfect. Class friend and member functions could still access them, and the errors would only be detected at link time. Alternately you could use boost noncopyable, but you can't always use boost. With the =delete syntax, errors are detected at compile time, and provide some semantic information about your code to anyone reading it.

Also, it's actually 6 implicit functions that compilers generate; you forgot about the copy-assignment and move-assignment operators.

Sorry but this is nonsense. Templates aren't any slower than hand-written code. Compilers may have had problems with templates a decade ago, but template support among the major compilers nowadays are very solid and consistent.

You say "many programmers minimize their use of templates, both in their own code and in their use of templated library code" -- are you saying "many" programmers writing C++ don't use boost or the standard library? Because that too is nonsense. Many bad programmers perhaps?

Lastly, partial specialization is very convenient for performing compile time recursion, which is pretty essential to template metaprogramming.

You could always just return a tuple, then use tie on the caller side. To use your example,

std::tuple SinCos(float angle) {
...
return std::make_tuple(sin, cos);
}

float sin, cos;
std::tie(sin, cos) = SinCos(angle);

Also, your last question isn't really a question, is it?

The assembler? Then how do you intend to compile anything into machine code? Must be quite a project you have there

Yes, that's what the PIMPL idiom is for. Here's a nice introduction to it .

As with most everything, there's a way to solve that problem in C++, it just takes some work and knowledge to know what, when, and how to use it. I do agree that the language is too big though; conceptually, C++ could be broken into 4 distinct components (C, STL, templates, OOP), as each have their own quirks and idioms that don't necessarily carry over well to the other, and some are even Turing complete on their own (ie template metaprogramming)