try to stump me on C++

[andersod2]

Hey all,

I got a big C++ interview coming up....and I am arrogant and think I am a C++ god...so see if you can stump my knowledge of the language. I solemnly swear I won't cheat and look up the answer, and you can feel free to rip me a new one in your responses. The only requirement is that you can't include anything about particular libraries or interfaces that aren't intrinsic to C++ (stl stuff is ok). The interview won't include things like that or other trivialities which can simply be referenced. They will be asking me things like "name the 3 ways you can blah blah" or "how could the following code be improved...what is the security or memory problem...what weaknesses does it have etc"

Show me what you got! Put me in my place and make me feel like I am going into this interview a lot dumber than I think!

Thanks to all who decide to participate...I owe you one.

[GCDEF]

Knowledge of the syntax doesn't make you a good programmer.

[Duoas]

Yes, but it is often indicative of one. The more a person know about a language's features the more time that person has probably spent using the language. And the more comprehensive that knowledge, the more likely he is a good programmer (or at least not a cheating, lazy one).

In any case, interviewers like dumb questions like:

Why is the following bad:

class foo
  {
  ...
  foo( const foo& x )
    {
    *this = x;
    }
   ...
  };

(Not an actual quote.)

Hope this helps.

[edit] Oh, BTW, that is a very real, very valid question.

[GCDEF]

Good programming is about logic, problem solving and decomposition. Syntax is secondary. When I interview people, I don't ask any C++ or syntax questions at all. Who cares. I want to know what problems they've solved, how successful they were and how they went about it.

[Paul McKenzie]

Good programming is about logic, problem solving and decomposition. Syntax is secondary. When I interview people, I don't ask any C++ or syntax questions at all. Who cares. I want to know what problems they've solved, how successful they were and how they went about it.

I knew someone who knew all the nuances of the Windows API. The problem is he couldn't write a real program if his life depended on it...

Regards,

Paul McKenzie

[GCDEF]

I knew someone who knew all the nuances of the Windows API. The problem is he couldn't write a real program if his life depended on it...

Regards,

Paul McKenzie

Me too. Whatever new technology came out, he immersed himself in it. STL, Com, whatever it was, he knew it inside out. His knowledge of syntax and tricks is way beyond what mine will ever be. Despite his immense knowledge, his code is unmaintainable junk. I remember taking a very long time trying to explain to him how to calculate an arithmetic mean.

[TheCPUWizard]

Complete agreement with all of the previous assesments.

But this is a favorite of mine...

static int X = f();

int f() { return X; }

int main()
{
   cout << X << end;
}

[andersod2]

thanks for your reply duoas,

Ok without cheating....basically you never want to modify the "this" pointer, expecially this way. In fact, this could be an example of the worst case scenario use of *this. It is usurping the allocation of the class (major memory leak). It's also potentially wreaking havoc with the "new"-ing of this class, potentially forcing some kind of access violation. Lot's of negative implications with modifying *this, and should almost never be done. Alternatively, to properly copy an instance of a class, do a member-wise copy in your copy constructor, or simply leave out the copy constructor and the operator= overload and the default behavior will be do implement those functions behind the scenes. Or, if it really was one's intention to simply create a second pointer to the same exact memory space, one can just declare a pointer to that class (or it's parent if applicable), and set the pointer to the first instance's address....

That was a good question...hope I got it right...

Any more?

[andersod2]

haha...good one CPUWizard....ok, you got me on that one....I knew it was a compile error, but I didn't see it clearly....once I compiled it though, it made sense....comes down to compiler choices I would think..

[Duoas]

@GCDEF, Paul McKenzie
I said more likely, not absolutely. I've known my share of 'real programmers' too...

Quite simply, much of the time people doing the hiring are mid-level managers who know very little about actually good programming. If your company doesn't hire that way then you seem to be in a good place.

I would hire people the same way you do.

@CPUWizard
LOL Nice one!

@andersod2
You did, and very comprehensively too. :-)

[Zaccheus]

"Is it at all possible to create a local function inside a function in C++? If so, how?"
"Why might you write a pure virtual destructor with inline implementation?"

[Zaccheus]

@andersod2
You did, and very comprehensively too. :-)

Did he? Personally I found the answer a bit vague but then so was the question. What are the data members? How is operator= implemented.

My question to andersod2 would be: What exactly do you think might happen if the only data member were an std::string or a boost smart pointer?

My answer to Duoas' question would have been that operator= should be implemented via the copy constructor, not the other way around. Using operator= in the copy constructor is either wasteful or downright catastrophic. Because the operator= will assume that the class is already fully constructed, it might try to delete a data member pointer which has not yet been initialised.
And if operator= has correctly been implemented using the copy constructor, an infinite recursion would very quickly crash the application.

[andersod2]

> "Is it at all possible to create a local function inside a function in C++? If
> so, how?" "Why might you write a pure virtual destructor with inline
> implementation?"

All right! Now that's the kind of BS I'm talking about. Ok, I won't cheat.

(1) The important part is, in any case, you would never want to do that. But I'm going to go ahead and say "yes, you can do it." I'm going to say use a label, some brackets, and a jumping method of some type (be it with an inline assembly jmp or...does C++ have a goto statement? haha)....then manage the stack yourself etc. That would be the hard way. If you can use built-in syntax is something I don't even want to know, but my instincts tell me that yes you can because a function call is merely a standard set of actions that are performed according to a calling convention. If one of my employees ever tried it, I'd make them wear their underwear on their head outside in the cold.

(2) Well as with anything in C++, there's always a lot of good reasons to do something no matter how crazy it seems...and this does seem crazy at first glance, but let's just look at it according to what we know. Of course, virtual destructors are what you want just about any time you are using derivation (and definitely if you're using virtual functions). So if we extend that idea out to pure virtual, it just means that we don't want our base-class doing any destruction whatsoever. That could mean the base class was composed of no data to begin with, or for some reason we want to usurp the typical destruction order. But I think the main reason would be that somebody with no knowledge of the class in question is responsible for destroying it via a base class pointer. It would be part of a high-level architecture. The base-class pointer is all the user code would have, so it couldn't know which destructor to call. This is also a good high-performance/efficiency thing since there's no function overhead, and no multiple function calls.

Great questions! Keep 'em comin'!

[andersod2]

> Did he? Personally I found the answer a bit vague...

yes, and vague usually gets the job

> My question to andersod2 would be: What exactly do you think might
> happen if the only data member were an std::string or a boost smart
> pointer?

Well I think you were right in your operator= comments. My comments were based on the assumption that the operation was possible, or that you didn't dereference the "this" pointer and were just casting away the uniqueness of everything to make it a legal operation. If that were the case, then the same comments would be in effect, namely memory leak for sure, and possibly a program crash on destruction. Otherwise, like you say, I think this operation would probably not even be possible to compile/link at best, and catastrophic failure at worst. For it to work, the operator= would have to be defined without the need for any copy construction....sort of like a copy constructor :P

[Zaccheus]

Local function:

void f()
{
    struct Local
    {
        /* Can only be called from inside f(). */
        
        static int average(int a, int b)
        {
            return (a+b)/2; 
        }
    };

    int x1 = 3;
    int y1 = 5;

    int x2 = 6;
    int y2 = 8;

    int z1 = Local::average(x1,y1);
    int z2 = Local::average(x2,y2);
}

Regarding the pure virtual destructor with inline implementation.

Defining a pure virtual destructor can be useful if (for some reason) you want an abstract base class when there are no other pure virtual functions in that class (I know some would argue against doing that, but that's another matter).
The important thing to remember is that even a pure virtual destructor will always need to be defined, even though it is pure virtual, because the derived class will call it. And if it is trivial (or even empty) then it might as well be inlined.