Interview questions

[cj]

Dear friends, I have one more questions for everyone in the newsgroup:

I am preparing for an interview on UNIX/C++. Could you please identify some
of the most important questions which might be asked, so that I could best
prepare for it?

Thank you,
C++J

[Ioannis Vranos]

JKop wrote:

Opps, that wasn't my intention, this was my intention:
int main(void)
{
int monkeys[7] = { 3, 4 ,3, 2 ,2 ,34, 23};

std::cout << reinterpret_cas t<char&>(monkey s[5]);
}

That's dangerous, you are passing to ostream::operat or<<() a char & to a
temporary.
What you probably meant to do is:

#include <iostream>
int main(void)
{
int monkeys[7] = { 3, 4 ,3, 2 ,2 ,34, 23};

std::cout << static_cast<cha r>(monkeys[5]);
}

Also reinterpret_cas t is the *last* of castings you should use, and
except of that, always try to avoid using castings at all.


Regards,

Ioannis Vranos

[JKop]

Ioannis Vranos posted:

JKop wrote:

Is reinterpret_cas t stupid, by which I mean does it do any processing
at all? For example, take the following:

unsigned char jk;

reinterpret_cas t<unsigned long&>(jk) = 4000000000UL;

Opps!! static_cast was what I was after:
unsigned char jk;

static_cast<uns igned long&>(jk) = 4000000000UL;
Here's an excerpt from http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/vccelng/htm/express_74.asp :

This behavior also applies to types other than class types. For instance,
static_cast can be used to convert from an int to a char. However, the
resulting char may not have enough bits to hold the entire int value. Again,
it is left to the programmer to ensure that the results of a static_cast
conversion are safe.

union {

double double_data;
int int_data;
char char_data;
unsigned long unsigned_long_d ata;
void* void_pointer_da ta;
float* float_pointer_d ata;

} monkey;

//Now some funky code:

double recpoo;

static_cast<flo at*&>(recpoo) = &some_global_fl oat;

static_cast<uns igned long&>(recpoo) = 4000000000UL;

static_cast<cha r&>(recpoo) = 'g';
-JKop

[Ioannis Vranos]

JKop wrote:

Opps!! static_cast was what I was after:
unsigned char jk;

static_cast<uns igned long&>(jk) = 4000000000UL;

That doesn't compile. However as I said in another message, casts are to
be used on the assigned value, not the object that gets that value.


Regards,

Ioannis Vranos

[Ioannis Vranos]

Ioannis Vranos wrote:

JKop wrote:

Is reinterpret_cas t stupid, by which I mean does it do any processing
at all? For example, take the following:

unsigned char jk;

reinterpret_cas t<unsigned long&>(jk) = 4000000000UL;

Reinterpret_cas t performs a value conversion. It doesn't modify anything
on the implementation of jk. So the above has essentially no effect. It
is as if you had written

unsigned char jk;

reinterpret_cas t<unsigned long&>(jk);

jk=4000000000UL ;


Regards,

Ioannis Vranos

[JKop]

JKop posted:

This behavior also applies to types other than class types. For
instance, static_cast can be used to convert from an int to a char.
However, the resulting char may not have enough bits to hold the entire
int value. Again, it is left to the programmer to ensure that the
results of a static_cast conversion are safe.

This excerpt seems to be bullshit. Try running the following on your system.
If the above was true, then the end output should be all 255, assuming that
your system is 8-Bit char and 32-Bit long.
#include <iostream>

int main(void)
{
unsigned char jk[4] = { 0, 0, 0, 0 };

std::cout << "jk[0] == " << (int)jk[0]
<< "\r\njk[1] == " << (int)jk[1]
<< "\r\njk[2] == " << (int)jk[2]
<< "\r\njk[3] == " << (int)jk[3]
<< std::endl;

std::system("PA USE");

static_cast<uns igned long>(jk[0]) = 0xFFFFFFFF;

std::cout << "jk[0] == " << (int)jk[0]
<< "\r\njk[1] == " << (int)jk[1]
<< "\r\njk[2] == " << (int)jk[2]
<< "\r\njk[3] == " << (int)jk[3]
<< std::endl;

std::system("PA USE");
}
static_cast isn't as special as I thought. I thought it would've been able
to achieve what unions do. Ah well!
-JKop

[E. Robert Tisdale]

Siemel Naran wrote:

I think [that]
the virtual table is implemented as an array of pointers to functions.
A jump table.
It works well whenever a pointer to a function
of any signature has the same size, which is normally the case.
If you have a class as follows.
Note what follows is a typical implementation,
not what the standard mandates.

class Foo { public: virtual ~Foo(void);
virtual int f(int, int);
virtual double g(int) const;
};

then the virtual table is an array of length 3.
Each element in the array is a function pointer,
but each function pointer is a different signature!
Sure, the compiler can do that, but we can't! cat main.cc class Foo {
private:
int F;
public:
virtual ~Foo(void) { }
virtual int f(int i, int j) {
int t = F;
F = i + j;
return t; }
virtual double g(int k) const { return F + k; }
};

int funny(Foo& foo) {
return foo.f(13, 23);
}

int main(int argc, char* argv[]) {
Foo foo;
return funny(foo);
}
g++ -Wall -ansi -pedantic -O2 -S main.cc
cat main.s

[E. Robert Tisdale]

Mike Wahler wrote:

Yes, the standard does guarantee that
compliant code is portable to a compliant implementation.
Please cite and quote the passage in the standard
that "guarantees " this.
Of course,
compliant implementations do not exist for all platforms.

In fact, no compliant implementations exist for any platform.
The claim is vacuous.

The license that came with my GNU C++ compiler
includes the following disclaimer:

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

When you installed your compiler,
you were obliged to accept "similar terms and conditions".
Compliance with ANSI/ISO C++ standards is voluntary.
Programmers have no legal recourse against compiler developers
if their compliant programs will not port.

[Niklas Borson]

"Siemel Naran" <Si*********@RE MOVE.att.net> wrote in message news:<jr******* *************@b gtnsc04-news.ops.worldn et.att.net>...

"pembed2003 " <pe********@yah oo.com> wrote in message

possible function definition. The lookup (not sure how the actual
virtual table is implemented but if it's something like a binary tree
or hash table then...) thus takes appr. the same amount of time.

I think the virtual table is implemented as an array of pointers to
function. It works well whenever a pointer to a function of any signature
has the same size, which is normally the case. If you have a class as
follows.

Note what follows is a typical implementation, not what the standard
mandates.

class Foo {
virtual ~Foo();
virtual int f(int, int);
virtual double g(int) const;
};

then the virtual table is an array of length 3. Each element in the array
is a function pointer, but each function pointer is a different signature!
Sure, the compiler can do that, but we can't!

Sure we can. Here's how you might do something very similar in C. I haven't
tried compiling it, but I've done similar things in the past. (For example,
for anyone masochistic enough to do COM programming in C, the code usually
looks pretty similar to this once you strip away all the macros.)

/*
* Declaration of Foo in foo.h
*/
struct Foo_VTable;

typedef struct tagFoo {
Foo_VTable* _vptr;
} Foo;

struct Foo_VTable {
void (*dtor)(Foo* _this);
int (*f)(Foo* _this, int, int);
double (*g)(Foo const* _this, int);
};

void Foo_ctor(Foo* _this);
void Foo_dtor(Foo* _this);
int Foo_f(Foo* _this, int, int);
double Foo_g(Foo const* _this, int);

/*
* Implementation of Foo in foo.c.
*/
struct Foo_VTable const g_Foo_vtable = {
&Foo_dtor,
&Foo_f,
&Foo_g
};

void Foo_ctor(Foo* _this)
{
_this->_vfptr = &g_Foo_vtabl e;
}

/* etc. for other member functions */

/*
* The following is essentially equivalent to what
* in C++ would be written:
* Foo foo;
* foo.f(0, 0);
* foo.g(0);
*/
Foo foo;
Foo_ctor(&foo);
foo._vfptr->f(&foo, 0, 0);
foo._vfptr->g(&foo, 0);
foo._vfptr->dtor();

/*
* The following is essentially equivalent to what
* in C++ would be written:
* Foo* foo = new Foo();
* foo->f(0, 0);
* foo->g(0);
* delete foo;
*/
Foo* foo = malloc(sizeof(F oo));
Foo_ctor(foo);
foo->_vfptr->f(foo, 0, 0);
foo->_vfptr->g(foo, 0);
foo->_vfptr->dtor();
free(foo);

[E. Robert Tisdale]

Niklas Borson wrote:

Sure we can.
Here's how you might do something very similar in C.
I haven't tried compiling it,
but I've done similar things in the past. (For example,
for anyone masochistic enough to do COM programming in C,
the code usually looks pretty similar to this
once you strip away all the macros.)

// Declaration of Foo in foo.h

struct Foo_VTable;

typedef struct tagFoo {
Foo_VTable* _vptr;
Should be

const void* _vptr;
} Foo;

struct Foo_VTable {
void (*dtor)(Foo* _this);
Should be

void (*dtor)(const Foo*);

You need to be able to destroy const objects
as well as variable objects with the same destructor!
int (*f)(Foo* _this, int, int);
double (*g)(Foo const* _this, int);
};

void Foo_ctor(Foo* _this);
void Foo_dtor(Foo* _this);
Should be

void Foo_dtor(const Foo*);
int Foo_f(Foo* _this, int, int);
double Foo_g(Foo const* _this, int);
// Implementation of Foo in foo.c.
#include "foo.h"

// Actually, the struct Foo_VTable definition
// belongs here and *not* in the public header file.
struct Foo_VTable const g_Foo_vtable = {
&Foo_dtor,
&Foo_f,
&Foo_g
};

void Foo_ctor(Foo* _this) {

_this->_vfptr = &g_Foo_vtabl e;
}

// etc. for other member functions
// The following is essentially equivalent to what
// what in C++ would be written:
// Foo foo;
// foo.f(0, 0);
// foo.g(0);

Foo foo;
Foo_ctor(&foo);
foo._vfptr->f(&foo, 0, 0);
foo._vfptr->g(&foo, 0);
foo._vfptr->dtor();
Should be

foo._vfptr->dtor(foo);


// The following is essentially equivalent to what
// in C++ would be written:
// Foo* foo = new Foo();
// foo->f(0, 0);
// foo->g(0);
// delete foo;

Foo* foo = malloc(sizeof(F oo));
Foo_ctor(foo);
foo->_vfptr->f(foo, 0, 0);
foo->_vfptr->g(foo, 0);
foo->_vfptr->dtor();
Should be

foo->_vfptr->dtor(foo);
free(foo);

Now suppose that you want to *derive* Bar from Foo

// interface
#include "foo.h"

typedef struct Bar {
Foo foo;
} Bar;

Bar Bar_ctor(void);
void Bar_dtor(const Bar*);
int Bar_f(Bar*, int, int);
double Bar_g(Foo const* _this, int);
char* Bar_hello(const Bar*);

// implementation
#include "bar.h"

struct Bar_VTable {
void (*dtor)(const Bar*);
int (*f)(Bar*, int, int);
double (*g)(Bar const*, int);
char* hello(const Bar*);
} Bar_VTable;

const Bar_VTable g_Foo_vtable = {
Bar_dtor,
Bar_f,
Bar_g,
Bar_hello
};

Bar Bar_ctor(void) {
Bar bar;
bar.foo._vptr = (const void*)(&g_Foo_v table);
return Bar;
}

// etc.

// usage
Bar bar = Bar_ctor();
Foo* pBar = (Foo*)(&bar);
((const struct Foo_VTable*)(pB ar->foo._vfptr))->f(pBar, 0, 0);
((const struct Foo_VTable*)(pB ar->foo._vfptr))->g(pBar, 0);
((const struct Foo_VTable*)(pB ar->foo._vfptr))->dtor(pBar);

[Peter Koch Larsen]

"Ioannis Vranos" <iv*@guesswh.at .grad.com> skrev i en meddelelse
news:cb******** ***@ulysses.noc .ntua.gr...

Ioannis Vranos wrote:

E. Robert Tisdale wrote:

How much more time it takes for the implementation to find and invoke
base999999::som ething()
in comparison to base78::somethi ng()?

It depends upon the implementation (compiler).
In the typical implementation, it takes no more time.
The C++ computer programming language standard
does *not* specify implementations , performance or efficiency.

Wrong. Next please. :-)

But I forgot to give you a reference. "The C++ Programming Language" 3rd
Edition or Special Edition, page 324.


Regards,

Ioannis Vranos

Well.... however brilliant "The C++ Programming Language" might be, it can
not answer your question.
You better consult the C++ standard for for answers to questions of that
caliber.
/Peter