Hacker News Reader

Comment by kabdib | Hacker News Reader

I have three standard "screener" questions: (a) what's a virtual method, (b) why would you want to have a destructor be virtual, and (c) what's a virtual base class.

Most folks (if they have a head on their shoulders) get A, a lot get B, and C befuddles almost everyone. (There are a few situations where you'd want to use a virtual base class. And if someone replies, "Oh yeah! I use those all the time!" they're probably using /other/ parts of the language that are just as unsavory).

Related to the original discussion: I've found the folks who self-rate themselves (on a scale of 1-10) as nines (and one guy was a ten) are generally bozos. This is independent of the language in question.

View on HN

I've been using C++ as my primary language for the last 10 years and know what virtual base classes are. I would never use them, Instead I'd avoid diamond inheritance at all costs.

I'd rate myself as a 9 or 10 for language proficiency but perhaps not for certain niches. For example I know comparably little about Win32 or COM (ugh).

However, there are tons of programmers out there who can't program. Faced with a clean slate they would either choke or create an atrocity. If they rated themselves 5/10 then for me to rate myself only 8/10 would be a disservice to myself. The same is true of perhaps 90% of the programmers on HN.

Of course, I can look back at my former self and know that he thought he was awesome but clearly I have surpassed his ability. It only makes sense that there are far greater programmers out there and I have met a few.

Right. The bit about virtual base classes is to simultaneously find the folks who know what it is, and to get a good feel for their design sense.

"Don't know" is okay, if they're otherwise a strong engineer. "Love them!" is only good if they can justify it. "Yeah, diamond inheritance, avoid that" is pretty much what I'm looking for, though I'm willing to have a serious conversation about their merit.

These are just questions I can get through in a minute or two, to gauge the person quickly.

I think that LinkedListItem or RefCounted are good candidates for sane virtual base classes.

I guess you'd never hire me: http://github.com/scotts/cellgen/blob/offstencil/src/xformer...

"OpenMP like support for the Cell Processor"?

Where do I sign?

All the code is there. It's part of my dissertation, which I'm trying to finish up: http://people.cs.vt.edu/~scschnei/cellgen/

I have a more in-depth paper that was rejected last year which I'm trying to extend right now. If you'd like to read it, you can. I have another paper under review that uses my work to make a Cell, GPU and Quad Core performance comparison.

I used to think a good C++ screener question might be: "When would you use the 'nothrow' constant, and when would you have empty 'throws' specifications in method declarations?"

But then I realized this is just getting tricky with C++ arcana, and is unfair. I once read all of Herb Sutter's 'Exceptional C++' series, and they scared me so much that I still get the frights, years on, when contemplating approaching a C++ compiler.

And I used to think I was OK with C++ too. But after Sutter's books I had to accept that, nah, at best I was mediocre. I admire people who can boldly cast out and rapidly prototype a library or something. Or who have the patience to iteratively engineer a Boost library. I will never achieve this, despite once desperately wanting too.

So you're asking for OOP, no generic programming / templates? I know template metaprogramming magic becomes madness real fast :-)

I tend not to ask direct language questions anymore, everything is related to the code written on the interview. Like, you asked for a function doing something with an array of ints, and when you get the code you say "now, can we have this function work with arbitrary types instead of just int", "what are the constraints about this types", "what happens if it has a copy constructor but no assignment operator" etc.

And I accept everyone knows and uses some subset of the language.

Long as you don't need any honest 9s or 10s for whatever it is you're doing, I guess that's fine.

Snarky answer: You can easily tell the 9s or 10s because they answer "eight."

Less snarky: They give you evidence, really quick, that they're a 9 or 10. It's not hard to tell.

A better question is: Why do we need to put the archaic virtual keyword in front of a method? Shouldn't non-virtual functions used in an inheritence way be declared as private while the other being automatically virtual ?

Then if he agrees, he's ok. If he gives you more examples of why C++ is archaic, he's great. If he begins talking about non-virtual methods being more optimized than virtual one, thanks him for his time and try to find someone else.

Public non-virtual functions may be useful. For example, to provide alternative API functions. Something like:

  virtual public setOrigin(const Point &p);
  public setOrigin(float x, float y) { setOrigin(Point(x,y)); }

Someone inheriting from this class will know that all the customization is in one function.

Still, I find it more logical to say virtual by default and using another keyword for rare case when you want to specify a non-virtual function.

Sure, if you learned to code in dynamic langs like Python and Ruby.

I didn't, I learned in C. I'd rather take the safe route and non-virtual by default.

> If he begins talking about non-virtual methods being more optimized than virtual one, thanks him for his time and try to find someone else.

What's your problem with this answer? Non-virtual methods can be easily inlined, whereas virtual methods (almost always) require:

1. a load (though a hoistable one) from the vtable

2. an indirect branch

3. register re-allocation

4. function call overhead (standard prologue/epilogue)

That is only a problem if and only if that method is being called in a very tight loop and its body is not particularly time consuming. A person making optimisations like this without first timing the code or at the very least spending some time introspecting on the pros and cons of doing so would not be someone I wanted to work with!

Tell that to someone writing a PlayStation 2 game. Using virtual functions without thinking will kill performance on that machine.

What if he makes a case for keeping types as POD when possible? :)

Anyway, it is clear from your comment that you dislike C++ and you prefer to hire people who agree with you that C++ is archaic, that is fine and all, but it doesn’t show in-depth understanding of the language. Explaining why things are as they are does show deep understanding of the language and a desire to learn the dirty details, IMHO a valuable trait.

It's a way to avoid a 100% only (and closed mind) C++ programmer. Understanding the cost of a virtual function is something. Not understanding that in most situation this cost is trivial, is something else. And every C++ great programmer should know that C++ is archaic and that higher level languages exist. If someone only knows C++, he is a C++ programmer, not a programmer.

Virtual functions are helpful only when you have derivation and need some common interface. When your class is not meant to be derived from, declaring functions as virtual is just plain misleading. And I am strongly against fitting everything artificially into a class hierarchy, that is, I dislike using the OOP sledgehammer for every simple class.

Also, great C++ programmers are those who use C++ in a problem domain matched to it, not those who use C++ where Perl or Python or something else is so much better. So they know that C++ is not archaic at all, it is just not suitable for every job, but then, what language is?

IMO, you shouldn't dismiss a candidate as close minded with one question. If you have fears that he only knows C++ and doesn't care about higher level languages, you should digg into that with other questions.

C++ is used in places other than bleeding edge PCs, you know. The impact of a virtual function call is non-trivial on some systems, the most prominent one that springs to mind is the PlayStation 2. Knowing how they work and when to use them is always a good thing. With that sort of attitude you'll only hire people less competent than yourself; you're trying to find more competent people.

Thanks for saying I'm not competent. First, I know what a virtual function is and how performance might be important. However, it's just illogical to use inheritences and OO without using virtual function. Just think about the virtual destructor.. why isn't it automatically virtual?

I find the inverse more interesting: Virtual by default and declaring non-virtual when the rare need arrives.

Thanks for saying I'm not competent.

This isn't what I said, but you know that anyway.

Just think about the virtual destructor.. why isn't it automatically virtual?

Basically, because not every class is used polymorphically, many are designed to be used primarily on the stack or as members. The merits of what should be the default are debatable, but as with anything in C++, the reason is probably historical. For example, it would break all C code that used structs. One of the C++ design principles is to not impose features upon you that you don't need, so that might be why they decided not to e.g. make classes have virtual functions by default, but not structs, a bit like classes have private members and bases by default.

In any case, these are straw man arguments. The point I was trying to make is that you suggested turning down people because they know the low-level details of the platform and their implications. I counter that this is a phenomenally bad idea; knowing what lies beneath the abstraction is always a good idea, especially if that reveals dragons.

You haven't said anything to counter that, instead pointing out aspects of C++ you don't like. If you dislike C++ enough not to use it, why are you interviewing people for C++ programming positions anyway?

Basically, because not every class is used polymorphically, many are designed to be used primarily on the stack or as members.

I also see classes used as members in Smalltalk. I wonder if a language can make the use of these sorts of objects explicit? Seems like there should be a good opportunity for better optimization.

The problem with that (in C++) would be that

  A a;
  A* p = new A;
  assert(sizeof(*p) == sizeof(a));

This wouldn't be true and cause all sorts of trouble (arrays, etc.) if a had no pointer to a vtable, but *p did. Moreover, you can take the address of a stack/member object, so how would you distinguish the two types? You'd literally need to modify the type system, and that would cause trouble with templates, etc.

I'm not thinking of this in C++ or Smalltalk. I'm thinking of a feature in another language.

You are right that knowning low-level detail of a language is great and I have badly explained what I meant to say in my first post (Mostly because I'm a terribly bad english speaker). Here is what I meant to say: C++ is archaic for a lot of reasons; just read effective C++ of any book and you'll find subtile bugs that you need to avoid.

My point is: I don't say whether C++ is bad or not but when you compare it to scheme or python, for instance, you clearly see that there're some archaic parts. Some programmers only know C++ and have closed mind on everything else. If they start arguing about the glory of those "c++ design error", it's a huge hint that it's a C++-only programmer.

OK, I'll quite happily agree with that. I'm generally wary of people who won't venture outside one language (one-trick ponies). I personally try to avoid using C++ except where it's clearly the best choice, mostly because I used it as my main language for the best part of a decade (high performance computing and game development). The thing is, C++ is still possibly the best choice in that narrow segment where C alone is too tedious but a high-level language won't work for some reason.

Modern C++ rarely use subclassing¹. The default in my code should certainly be non-virtual.

Someone already mentioned the performance issue. This applies both to run-time but also memory. Imagine we introduce a new type called ‘point’ representing a 2D point. We may have millions of these and we may store them in vectors, here we do not want to pay for the memory overhead of adding a jump table to each point in this vector (or initializing such pointer when constructing points, going through the jump table when doing “simple” math with the points etc.).

¹ Although the substitute for subclassing to achieve polymorphism in C++ tend to be generic programming, many OO languages are advocating composition over inheritance.

Why C# also makes methods non-virtual by default: http://www.artima.com/intv/nonvirtual.html

Other (shorter) commentary: http://stackoverflow.com/questions/814934/why-c-implements-m...

One of the main design principles behind C++ was "you don't pay for what you don't use." Hence, if you don't want to use polymorhpic member functions, then you don't pay for the overhead.

Reply on news.ycombinator.com