Quote:Original post by dclyde
One thing to realize is that the person asking the questions doesn't always expect you to get all of them right, but rather they want to see how extensive your knowledge goes.

Yeah, I think this was the situation in this case.

The "stuff behind your back" goes way deeper than puny vtable.

Consider:

a = b;

What does this code do?

In C, a will have the value of b.

In C++:
- assignment operator is invoked
- copy constructor is called to make a temporary
- 3 internal pointers are assigned to std::auto_ptr
- 3 new calls are made
-- each new call is routed via custom overloaded new
-- which in turn calls malloc
-- which updates allocation table
--- which strcpy()s __FILE__ and __LINE__
- std::swap is called between local variables and temporary
- old state is delete[]d
- auto pointers are reset
- this is returned

And no, this is not far fetched, it is basically the default implementation of a default assignment operator of a class containing 3 exception-safe members, say, strings. For example:

struct Foo {  std::string x;  std::string y;  std::string z;};

And that is trivial case - double the complexity of the above could apply to every deep copy made.

This is primary reason why system programmers shun C++. Too much magic. And it really depends on perspective - this magic might be far from a good thing.

"Are you at liberty to divulge what sort of position you were interviewing for when these questions tend to arise?"

Oh god, I get asked these sorts of questions all the time -- and I'm usually interviewing for team lead/architect type roles these days.

Job interviews are generally really poor -- there's a lot of questions doing the rounds that frankly people can learn out of books. "What's a virtual function?", "What's the difference between a struct and a class?". Stuff like that. That's not even daily bread for developers. That stuff should be like air. You need it, but when was the last time you actually looked at it?

There are actually really few jobs where you need to do things like implement virtual dispatching in C or swap a string in place. I've done everything from video bioses to content delivery networks passing through City financials and logistics companies on the way and I've never actually needed either of them.

I've often said that I could get my sister past most software interviews with a couple of hours training on the rote answers to those questions -- whereas there's no way I could pass for a auditing accountant of her level without actually have done all the exams.

"What's the difference between a pointer and a reference" shows up a lot as an interview question as well. And it's amazing how many people think that a reference can't be null because that's what some of the textbooks say[1].

And don't get me started on the "How do you get four programmers who walk at different speeds across a bridge in the dark with only one torch" type crap...

I particularly like the way the people that do that say that they do it because Microsoft does it[2] rather than for any actual explainable reason -- that's not an interview technique, that's a cargo cult.

And then there's the people who just show code snippets and want to know why it won't compile or won't work -- usually based on exotic edge cases of C++. I went to one a few months back that contained TWO HOURS of that stuff with some autistic guy doing the interview. Brr. I went home, had a bath, washed my hair and STILL I could feel nerdiness clinging to me. My take on that crap is to steer well away from the edges of C++. We're in the business of writing software, not finding new and exciting compiler errors.


This is one of my issues with the software industry. It's like you're hiring a chief of surgery at a hospital, and the interview consists entirely of asking them if they can identify different types of scalpel, not whether they're any good at saving patients. It shouldn't really be a surprise that half the industries projects die on the table, although we can all name the kind of scalpel we used to open with.


[1] You can create a null pointer of the right type and * it into a reference of that type. Works just fine. You can even call methods through it and they'll work as long as they're not virtual. It will then crash on the first member access. "this" will, of course, be null. References are really just syntactically sugared pointers.

[2] But they don't give their developers individual offices to work in peace. Like Microsoft does...

First to make it work, then to make it work faster.
Intel optimization tricks...
http://www.agner.org
I like to code in C++ then find the slow spots and
replace them with some hand rolled assembly code.
A good assembler can beat the best compiler every time.
Now that we have SIMD technology it gets a bit trickier.

Quote:

Quote:
Original post by Antheus
In C++:
- assignment operator is invoked
- copy constructor is called to make a temporary
- 3 internal pointers are assigned to std::auto_ptr
- 3 new calls are made
-- each new call is routed via custom overloaded new
-- which in turn calls malloc
-- which updates allocation table
--- which strcpy()s __FILE__ and __LINE__
- std::swap is called between local variables and temporary
- old state is delete[]d
- auto pointers are reset
- this is returned

Out of curiosity, isnt that what the new 0x standard fixes using rvalue and lvalue references? At least thats what I got from what I read. I'm nowhere near an expert though so dont quote me =p

Sort of, but this concerns temporaries. If you need two deep copies of something, you still need to copy it.

I don't think it is necessarily that bad for C++. If you really need failure-safe deep copies in C, it's not going to be a = b, so it is rather a comparison of apples and oranges.

Quote:Original post by Antheus
The "stuff behind your back" goes way deeper than puny vtable.

Consider:

a = b;

What does this code do?

In C, a will have the value of b.

In C++: ...

The net result of which is, a will have the value of b, in what is really the simplest safe way.

There's nothing about the implementation of std::string that requires a std::auto_ptr, BTW, although it is "managed" memory in a sense. There's also nothing in the spec that I know of that would mandate a re-allocation every time - if the string being copied over was longer, there's no reason the old storage couldn't be reused. You're also forgetting about short-string optimizations. And that __FILE__ and __LINE__ stuff is only going to happen in debug mode.

Quote:it is basically the default implementation of a default assignment operator of a class containing 3 exception-safe members, say, strings.

Which you can't even create in C.