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]

Re: Some interview questions

* Sashi:[color=blue]
> 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?[/color]

It doesn't.

[color=blue]
> Ever need a virtual constructor?[/color]

Is that a question?

See the FAQ on virtual constructors.

Possibly your interviewer hadn't read the FAQ.

[color=blue]
> Major difference between public and private inheritance (other than the
> obvious one)?[/color]

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_?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Gernot Frisch]

Re: Some interview questions


"Alf P. Steinbach" <alfps@start.no > schrieb im Newsbeitrag
news:42aeef8f.8 75878828@news.i ndividual.net.. .[color=blue]
>* Sashi:[color=green]
>> 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?[/color]
>
> It doesn't.[/color]

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.

[color=blue][color=green]
>> Ever need a virtual constructor?[/color]
>
> Is that a question?
> See the FAQ on virtual constructors.
> Possibly your interviewer hadn't read the FAQ.[/color]

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)

[color=blue][color=green]
>> Major difference between public and private inheritance (other than
>> the
>> obvious one)?[/color]
>
> 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_?[/color]

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]

Re: Some interview questions

* Gernot Frisch:[color=blue]
>
> * Alf P. Steinbach:[color=green]
> > * Sashi:[color=darkred]
> > >
> > > Why does a copy constructor param need to be const?[/color]
> >
> > It doesn't.[/color]
>
> That doesn't help.[/color]

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

[color=blue]
> If you answer questions like these, you upset your possible boss.[/color]

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


[Re other stuff: see the FAQ]

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Gianni Mariani]

Re: Some interview questions

Gernot Frisch wrote:
....[color=blue]
> class Base
> {
> public:
> void foo();
> }
>
> class Derived : private Base
> {
> public:
> void foo2() {Base::foo();}
> }
>
> int main()
> {
> Base* pDerived = new Derived;[/color]

This should fail. You're accessing a privately inherited class.
[color=blue]
> pDerived->foo(); // what's it doing? (I don't know honestly)[/color]

This line should be ok.

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

[Kristo]

[OT] Re: Some interview questions

Alf P. Steinbach wrote:[color=blue]
> * Gernot Frisch:[color=green]
> >
> > * Alf P. Steinbach:[color=darkred]
> > > * Sashi:
> > > >
> > > > Why does a copy constructor param need to be const?
> > >
> > > It doesn't.[/color]
> >
> > That doesn't help.[/color]
>
> Course it does: it corrects the invalid assumption in the question.
>
>[color=green]
> > If you answer questions like these, you upset your possible boss.[/color]
>
> Who would want a technically incompentent person who believes she is
> technicallty competent, as boss?[/color]

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]

Re: Some interview questions



Kristo wrote:[color=blue]
> Alf P. Steinbach wrote:[/color]
[color=blue][color=green]
> > Who would want a technically incompentent person who believes she is
> > technicallty competent, as boss?[/color]
>
> I wouldn't, but I like a paycheck more than I dislike such a boss.[/color]

Specially with those wedding deposits and all.
[color=blue]
> 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.[/color]

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



Brian

[maadhuu]

Re: Some interview questions

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]

Re: Some interview questions


"maadhuu" <madhu_ranjan_m @yahoo.com> wrote in message
news:ade453352f 5923c2a69702bd9 ab1275a@localho st.talkaboutpro gramming.com...[color=blue]
> 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[/color]

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@math.com]

Re: Some interview questions

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]

Re: Some interview questions

>> If you answer questions like these, you upset your possible boss.[color=blue]
>
> Who would want a technically incompentent person who believes she is
> technicallty competent, as boss?[/color]

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

[maadhuu]

Re: Some interview questions

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

[wkaras@yahoo.com]

Re: Some interview questions

Sashi wrote:[color=blue]
> 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?[/color]

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.
[color=blue]
> Ever need a virtual constructor?[/color]

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.
[color=blue]
> Major difference between public and private inheritance (other than the
> obvious one)?[/color]

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).
[color=blue]
> Thanks,
> Sashi[/color]