Typical (technical) interview questions

Started by
57 comments, last by parasolstars 18 years, 4 months ago
Quote:
Q: What is a pure virtual method in C++?

Me: You dont have to define a pure virtual method of a class, only declare it, but you have to define it in a child class to instanciate it. Usually it is used to create interfaces of classes.

Q: Ok, but CAN you define it in the mother class?

Me: ... why would you do that?


Actually, technically you can't, because then it's not a PURE virtual method anymore. A pure virtual method is declared in the base object, has no definition, and has the syntax: virtual return-type method-name(parameter-list)=0;

A class can not be instanciated (is considered abstract) if it has one or more pure virtual functions that aren't yet defined in the class hierarchy.
Advertisement
Quote:
what is virtual inheritence?


Virtual inheritance solves the "diamond inheritance" problem, where there is some class A, which is the base class of two classes B and C, and a fourth class, D, inherits from both B and C. Using non-virtual inheritance, an object of type D has two copies of A in it, and must be qualified as D::B::A and D::C::A. If B and C virtually inherit from A, then class D will only have one, unambiguous copy of A and referenceing A does not require such explicit qualification.

Quote:
What's the difference between a pointer and a reference?


A reference is simply another name for an object, and does not occupy a place in memory. Thus, you cannot take the address of a reference, because it doesn't actually exist at runtime.

Quote:
what's the difference between prefix and postfix operators?


Postfix operators (like increment) require storing a temporary copy of the object being incremented, incrementing the actual object, and returning the temporary copy as a result of the expression. Prefix operators (like increment) increment the actual object and evaluate to the actual object.

Quote:
what is a virtual constructor?


There is no such thing. People wanting behavior that would seem like a 'virtual constructor' are usually talking about something like the factory pattern.

Quote:
why shouldn't you inherit from the standard library containers?


Becuase they don't define their destructors as virtual, and therefore their destructors will not be called when your derived version of them is destructed.
Quote:
Quote:Quote:

why shouldn't you inherit from the standard library containers?


Becuase they don't define their destructors as virtual, and therefore their destructors will not be called when your derived version of them is destructed.


This is true if you have a pointer to the base container class, the destructor for the derived class will not be called. If you have a pointer / reference to the derived class, then it will be destroyed in the correct order. Because you can never be sure if you have the top-most derived class, it isn't safe to inherit from them. OpenSceneGraph has several classes that inherit from the container classes, but you don't have to believe me. Try it yourself.
Deception666 - right, sorry. -1 for me :) Though I still think it's a bad idea to inherit from them, even if YOU take care to only delete them through a pointer or reference to the derived container class, someone else might not be so careful.
Quote:Original post by RDragon1
Quote:
Q: What is a pure virtual method in C++?

Me: You dont have to define a pure virtual method of a class, only declare it, but you have to define it in a child class to instanciate it. Usually it is used to create interfaces of classes.

Q: Ok, but CAN you define it in the mother class?

Me: ... why would you do that?


Actually, technically you can't, because then it's not a PURE virtual method anymore. A pure virtual method is declared in the base object, has no definition, and has the syntax: virtual return-type method-name(parameter-list)=0;

A class can not be instanciated (is considered abstract) if it has one or more pure virtual functions that aren't yet defined in the class hierarchy.

No, you can. The catch is that it is never implicitly called...concrete derived classes are still required to implement the function, and so those implementations will be called. At that point, you are free to explicitly call the base class's implementation. It is odd, and rare, but you can do it.

CM
Quote:
Quote:Quote:

What's the difference between a pointer and a reference?


A reference is simply another name for an object, and does not occupy a place in memory. Thus, you cannot take the address of a reference, because it doesn't actually exist at runtime.


Yes, a reference is simply another name for an object, and it DOES occupy a place in memory. You CAN take the address of a reference, because it DOES exist at runtime.

class IntRef{public:  IntRef( int * pInt ) : m_rnInt( pInt ) { };private:  int & m_rnInt;};


Assuming the compiler byte aligns to 4 bytes, this class would be 4 bytes in size, so a reference DOES occupy a place in memory. If I took the address of m_rnInt, I would have a pointer to a pointer of int. I would not be able to take the address of the reference if it did not exist at runtime, but because it is possible, it HAS to exist.
Yeah... Not sure why I thought what I said. Thanks for the correction.
Wow, this is some good stuff. Lots of ammunition to bone up on. :)

Quote:Original post by EndarA constructor is a function that is run on a section of memory that is allocated, either on the stack, or the heap. It's purpose is to set up an object of whatever class it is part of. Using the constructor, data members of a class can be initialized and their value changed from whatever garbage value is given to the memory by the operating system before it was allocated. The constructor is run before the object it is intended to construct can be used.

A destructor is called on an object when it is deleted. This means whenever a local variable of a class type that has a destructor defined goes out of scope, or an object is delete from the heap. They are usually used to delete memory that was dynamically allocated for that object.


This is typically about as far as I get when asked. What's going on with the memory allocation etc (ie, what sort of operations are running affecting the performance)? I once answered with roughly the same response as above and then was prompted for more information. All I could provide was a blank stare and some "hemming and hawing."

I just had a nightmare thought, I was JUST asked this question in an interview last week and I glossed over most of this stuff. I was assuming that he wanted to know the nitty gritty details. I hope he doesn't think I'm a complete fool who doesn't understand the most basic details!
Quote:Original post by Deception666
Yes, a reference is simply another name for an object, and it DOES occupy a place in memory. You CAN take the address of a reference, because it DOES exist at runtime.

The standard does not require that references occupy any space, and you are prohibited from creating references to references, or pointers to references. A reference *might* exist at runtime, but if the compiler is able to do away with that requirement it will do so.

CM
Quote:Original post by Conner McCloud
Quote:Original post by Deception666
Yes, a reference is simply another name for an object, and it DOES occupy a place in memory. You CAN take the address of a reference, because it DOES exist at runtime.

The standard does not require that references occupy any space, and you are prohibited from creating references to references, or pointers to references. A reference *might* exist at runtime, but if the compiler is able to do away with that requirement it will do so.

CM


After consulting a few reference materials, you are right. I can see where the compiler could remove the physical memory location of a reference within a function, but how about a class reference member variable? There has to be memory involved here? Does the compiler consider the reference to be a pointer but allow it to be treated as an object. Thanks.

This topic is closed to new replies.

Advertisement