Oh God I know the answers to all those interview questions and I remember using all those features and it seems like an unimaginable Cthulhoid horror now.
"How many ways are there to initialize a primitive data type in C++ and what are they?"
I guess the answer is two: implicitly at program startup or through assignment. But then, maybe he wants to differentiate between int j=0, int j(0), what constructors do in x::x : j(0){}, and whatever.
"What is name mangling in C++ and why is it used?"
There is no name mangling in C++. Some compilers do map names to C-compatible identifiers, but that is not C++'s business.
"What is a copy constructor and when is it used, especially in comparison to the equal operator?"
I do not have the standard at hand, but I would guess it has an equality operator and an assignment operator, or maybe even just 'assignment'.
"What is a Vector?"
What is that capital 'V' doing there? Should I assume a "using namespace std" and an "#include <vector>"?
"Why should you never throw an exception in a destructor?"
There is nothing wrong with throwing an exception in a destructor (well, it is a bit weird). Throwing one from a destructor is the no-no.
"What is the proper way to perform a cast in C++?"
Another trick question or badly phrased. What are the ways to cast values in C++? When are they appropriate?" or something like it would be better.
It really helps to know what goes on under the hood. For that, I'd say C++ has strong didactic value.
Lucky are the ones who have someone to teach them this stuff. If you have to find it out yourself it is an endless pain.
I think I could handle the Great Old Ones. But C++, never again.
"What is a vtable?"
My answer was that it was the way in which a C++ compiler makes it possible to do polymorphism (calling base member methods through pointers to derived classes; virtual functions). The interviewer didn't agree with me and said that vtables have nothing to do with polymorphism and moved on to another question (about :: scoping). I didn't start to argue with him, and I got the job.
Btw I assume you meant "calling derived member methods through pointers to base classes" instead.
I do have a certain amount of nostalgia for the days when all programming was pretty much "close to the machine". Now we spend our time gluing frameworks and libraries together to create apps.