Some interview questions

[Sashi]

All, I had an interview today and I couldn't answer these questions.
Any good answers?
Why does a copy constructor param need to be const?
Ever need a virtual constructor?
Major difference between public and private inheritance (other than the
obvious one)?
Thanks,
Sashi

 

[Alf P. Steinbach]

* Sashi:

All, I had an interview today and I couldn't answer these questions.
Any good answers?
Why does a copy constructor param need to be const?

It doesn't.

Ever need a virtual constructor?

Is that a question?

See the FAQ on virtual constructors.

Possibly your interviewer hadn't read the FAQ.

Major difference between public and private inheritance (other than the
obvious one)?

What's obvious is subjective, so that's a question that only you can answer;
the question is essentially, what's the major non-obvious for _you_?

 

[Gernot Frisch]

* Sashi:

It doesn't.

That doesn't help. If you answer questions like these, you upset your
possible boss. Argue with:

It doesn't. However it's clever to do so to create copies of const
objects. Also, the object copied from usually is not changed when
making a copy of it - however sometimes it _is_ required to be changed
ant thus, that's where the cctor mustn't have a const argument.

Is that a question?
See the FAQ on virtual constructors.
Possibly your interviewer hadn't read the FAQ.

If you do this:
CBase* pBase = new CDerived();
you will call the ctor of the _derived_ function. You can't call the
ctor of the base if you want to create the derived. (my english is
bad, hopefully the content is not)

What's obvious is subjective, so that's a question that only you can
answer;
the question is essentially, what's the major non-obvious for _you_?

Hmmm... What if you call a base class's public function of a privately
derived class?

class Base
{
public:
void foo();
}

class Derived : private Base
{
public:
void foo2() {Base::foo();}
}

int main()
{
Base* pDerived = new Derived;
pDerived->foo(); // what's it doing? (I don't know honestly)
}


HTH,
Gernot

 

[Alf P. Steinbach]

* Gernot Frisch:

* Alf P. Steinbach:

That doesn't help.

Course it does: it corrects the invalid assumption in the question.

If you answer questions like these, you upset your possible boss.

Who would want a technically incompentent person who believes she is
technicallty competent, as boss?


[Re other stuff: see the FAQ]

 

[Gianni Mariani]

Gernot Frisch wrote:
....

class Base
{
public:
void foo();
}

class Derived : private Base
{
public:
void foo2() {Base::foo();}
}

int main()
{
Base* pDerived = new Derived;

This should fail. You're accessing a privately inherited class.

pDerived->foo(); // what's it doing? (I don't know honestly)

This line should be ok.

BTW - this is somthing your compiler will tell you much faster than I.

 

[Kristo]

* Gernot Frisch:

Course it does: it corrects the invalid assumption in the question.



Who would want a technically incompentent person who believes she is
technicallty competent, as boss?

I wouldn't, but I like a paycheck more than I dislike such a boss. If
you're unemployed, nitpicking a potential employer is not going to
help. Nobody said you had to stay in a job where the boss was
incompetent. Take what you can get but keep interviewing for something
better.

Kristo

 

[Default User]

Alf P. Steinbach wrote:

I wouldn't, but I like a paycheck more than I dislike such a boss.

Specially with those wedding deposits and all.

If
you're unemployed, nitpicking a potential employer is not going to
help. Nobody said you had to stay in a job where the boss was
incompetent. Take what you can get but keep interviewing for something
better.

You're speaking theoretically, of course. Besides, WONDERFUL cow-orkers
can make up for other defects of the job. Right?



Brian

 

[maadhuu]

the reason as to why a copy constructor has to be constant and is passed as
a reference is as follows :

as in it should be like say foo(const foo& abc){ }

is because :

suppose foo is a class which has a variable (say data) for which memory is
allocated using new and it is destroyed using delete ,then if u have the
following in main

main()
{
foo a;
foo b(a); //copy constructor evoked
}

now if a is passed as an object,ur program is going to crash as u will
have a temporary object created ,which will also refer to the same memory
location and once it goes out of scope, the memory is destroyed and when
object "a" goes out of memory - u r trying to free the same momory !
hence,it is passed as a reference and why it is a const reference is for
the simple reason that if u have
const foo a;
in main,then this object cannot be used to initialize another object till
u accept it as a const object.
hope this answered ur question.all the best........the other 2 answers
were already explained.

 

[Howard]

the reason as to why a copy constructor has to be constant and is passed
as
a reference is as follows :

as in it should be like say foo(const foo& abc){ }

is because :

suppose foo is a class which has a variable (say data) for which memory is
allocated using new and it is destroyed using delete ,then if u have the
following in main

main()
{
foo a;
foo b(a); //copy constructor evoked
}

now if a is passed as an object,ur program is going to crash as u will
have a temporary object created ,which will also refer to the same memory
location and once it goes out of scope, the memory is destroyed and when
object "a" goes out of memory - u r trying to free the same momory !
hence,it is passed as a reference

But (assuming its body is properly written) wouldn't the copy constructor
itself take care of the internal pointer, either allocating new memory or
else using some kind of reference-counting scheme? I mean, that's usually
why one writes a copy constructor in the first place, when there is
dynamically allocated member data.

The problem with passing by value, I believe, is that such a scheme would be
infinitely recursive. To make the copy of the object being passed, the copy
constructor would be invoked, which would need a copy of the object, which
would invoke the copy constructor, which would...

I'm not sure what the standard says about it, but my compiler won't even
allow me to define a copy constructor where the parameter is passed by
value, probably because there's no way to resolve the infinite recursion.

-Howard

 

[binbag]

I recently gave a talk on C++ for interviews at 7City.
It was videoed (fame at last

It's available http://www.wilmott.com/detail.cfm?articleID=222

There's handouts if anyone cares.

DominiConnor
Quant Headhunter

 

[Gernot Frisch]

If you answer questions like these, you upset your possible boss.

Who would want a technically incompentent person who believes she is
technicallty competent, as boss?

Here in Germany unemployment rises. If you're in the east, you'll even
brush his shoes propably.

 

[maadhuu]

i totally agree with Mr Howard.....and i think ypu are absolutely right !!!
sorry for the mistake from my side!!

 

[wkaras]

All, I had an interview today and I couldn't answer these questions.
Any good answers?
Why does a copy constructor param need to be const?

Technically, the parameter to a copy constructor _has_ to be
a const reference only if you will be copying from const
instances.

But I think most would agree that it's counter-intuitive for
a "copy" operation to change the thing that's being copied.
Making the parameter a const reference gives an assurance
that the source of the copy is not changed.

Ever need a virtual constructor?

Yes. The inability to make a copy (outside the heap) of an object
when you only know its subclass is one of the limitations of
using virtual functions for generic code as opposed to templates.
But allowing virtual constructors or something equivalent for
stack variables would probably require drastic additions to
the language syntax. I don't see any way to do it without
breaking the rule (in Standard C/C++) that any object created
in the stack has a size known at compile time. (I don't
know what the value of this rule is, and GNU gcc has extensions
that break it anyway.) Hard to see how to use virtual constructors
for statically allocated variables because of the issue of the
size not being known at compile time.

Major difference between public and private inheritance (other than the
obvious one)?

They're _really_ deap sea fishing with this one. Some differences:

1) Can't address instances with pointer or reference to private
base class.

2) Even public members of private base class are inaccessable
in a dervived class instance from outside the derived class.

3) Can't be used to represent an "is-a" relationship (which is
basically saying the same thing as #1 but in a more non-obvious way).