Understanding the first rested on the fact that a friend function declaration requires that the relevant function declaration be present above it in the translation unit (e.g. friend int A::foo();" requires that "class A" be defined, even though the prototype is otherwise correct). Meaningless trivia, and something every compiler will remind you about instantly and clearly.
The second one was pretty straightforward and basically about understanding that a superclass constructor is invoked before the subclass constructor. That's certainly important to understand, but in my experience rarely misunderstood except by true OO newbies (basically the same behavior has to hold for any static type system with inheritance).
The third called a public virtual function through a superclass pointer and expected you to recognize that declaring the derived function private in the subclass that the object belongs to didn't matter. Again, trivia that doesn't correspond to any meaningful real-world code pattern.
You gave up too early. How about the question that tests your knowledge of std::async behavior, in a way that has very real practical results? (very real in that if you don't understand the behavior, you're almost certainly using std::async incorrectly and with no benefit to your code).
Or the one that makes sure you understand that, if a function isn't declared virtual, then you get static dispatch instead.
Or, heck, the one that ensures you know that floating-point literals default to double, and that this fact affects function overload resolution.
I don't write C or C++, but I do write a lot of C# and some occasional obj-C. Maybe I will get down voted for this, and I completely see merit in learning all you can about a language and features as it makes developers more valuable to their employers.
<now for the but>
In my over 10 years as a developer, I rarely if EVER come across these sorts of problems. I've been in many problem domains and modeled many sorts of problems. I have come across these sorts of issues maybe 1 or 2 times. When I did come across this sort of problem a few hours of thought allowed me to come up with a rational solution that didn't require stretching the bounds a of a language.
</but>
So while Im all for academic curiosity and figuring out the way things work, I dont know that these sort of things are applicable as to whether someone can write code to do a job that is robust, scalable and reliable.
So please excuse me while I go read my C++ books because I feel stupid...
That's a pretty valid <but>...</but> tag. However, I would argue (based on what I know of software development and the stories that I've seen posted on occasion on HN) that knowing some of these oddities and details can come in a lot of handy someday. Even careful developers can accidentally run into some strange scenario which turns into one of these rarely-seen specifications, causing some bug. If you don't know these kinds of things, you'll have no clue where the bug could be coming from. And this is especially true in a language that can be as thorny as C++.
As an example, in a program I'm working on which is still some ridiculously simple 100-line program, I shadowed a variable name inside a loop. (C++) I figured it would be ok because I was declaring the new variable after I was done using the previous one. But apparently, declaring a variable at all in a scope causes the new variable to be the one used inside that scope, even from the beginning. And considering the two variables were of a different type, it was causing a problem. Not hard to find in a small program, but might be harder to find in a large one.
On the flipside, a lot of these issues might be relatively easy to find with a little intelligent Googling or asking Stack Overflow. But that time might have been better spent continuing development on the current project. And that time can add up.
Haha yeah. I agree with you totally, however sometimes when the problem is a bug in another system and everything still seems completely rational this kind of knowledge is gold.
My story was a C# WPF application and certain events were not being unregistered. It wasn't the language built in event registration but a weak even registration handler in a WPF library.
It wasn't unregistering the event and it was odd to say the least because it was just an equals call. It turns out that the function was an anonymous function (that was defined as x = {...};) The strangest thing is that the anonymous function had a reference to it and I had thought that the references were being compared for equality.
But it wasn't being matched... So I recommended the inline declaration be changed to an actual static method and the comparison worked. I think I gave some kind of explanation about how it most likely compared the address of the methods or something. Or the comparer for a Action<T> was different than "normal" objects. Half the fun of it is figuring out how things really work behind the scenes though. For the person figuring it out though.
As a long-time (hobbyist) C++ programmer, I'd say many of the questions in the quiz are well-known gotchas that do break real-world code in subtle ways. Especially code by beginners that have Java or C# experience and expect C++ to be as well-mannered. That said, many other questions certainly pertain to more esoteric parts of the language, but that's not a bad thing - it provides some entertainment and headscratching even to those of us who might think they've seen it all :)
Yeah, this special case always weirded me out, it's hard to see a justifiable use case. In regular usage you'd use auto& instead to achieve the same effect.
Indeed. C++ is filled with so many of these by now that anyone claiming expertise on the language must bear name of one of the commonly known C++ gurus.
The question is what should someone say about his/her level of expertise when asked by a recruiter? I have been comfortably programming in the language for the past 15+ years, still feel shy about claiming myself to be an expert.
I thought I read somewhere that Bjarne himself thought he wasn't above a 7 on a one to ten scale. So, you know the recruiter will expect you to say at least a 9 and HR will expect nothing less than a 10.
This [1] is my candidate for why I'm not cut out to be a master C++ programmer. There's far too many arcane rules. I want to use a language I can enjoy.
In fairness to C++, that rule mostly has effects where it silently does the right thing even if you don't know the rule rather than breaking things. It's just kind of surprising when it fixes code that looks broken.
24 comments
[ 3.0 ms ] story [ 56.2 ms ] threadUnderstanding the first rested on the fact that a friend function declaration requires that the relevant function declaration be present above it in the translation unit (e.g. friend int A::foo();" requires that "class A" be defined, even though the prototype is otherwise correct). Meaningless trivia, and something every compiler will remind you about instantly and clearly.
The second one was pretty straightforward and basically about understanding that a superclass constructor is invoked before the subclass constructor. That's certainly important to understand, but in my experience rarely misunderstood except by true OO newbies (basically the same behavior has to hold for any static type system with inheritance).
The third called a public virtual function through a superclass pointer and expected you to recognize that declaring the derived function private in the subclass that the object belongs to didn't matter. Again, trivia that doesn't correspond to any meaningful real-world code pattern.
I gave up after that. Yawn.
Or the one that makes sure you understand that, if a function isn't declared virtual, then you get static dispatch instead.
Or, heck, the one that ensures you know that floating-point literals default to double, and that this fact affects function overload resolution.
The next logical step is to start defining or disallowing more of the undefined ones.
<now for the but> In my over 10 years as a developer, I rarely if EVER come across these sorts of problems. I've been in many problem domains and modeled many sorts of problems. I have come across these sorts of issues maybe 1 or 2 times. When I did come across this sort of problem a few hours of thought allowed me to come up with a rational solution that didn't require stretching the bounds a of a language. </but>
So while Im all for academic curiosity and figuring out the way things work, I dont know that these sort of things are applicable as to whether someone can write code to do a job that is robust, scalable and reliable.
So please excuse me while I go read my C++ books because I feel stupid...
As an example, in a program I'm working on which is still some ridiculously simple 100-line program, I shadowed a variable name inside a loop. (C++) I figured it would be ok because I was declaring the new variable after I was done using the previous one. But apparently, declaring a variable at all in a scope causes the new variable to be the one used inside that scope, even from the beginning. And considering the two variables were of a different type, it was causing a problem. Not hard to find in a small program, but might be harder to find in a large one.
On the flipside, a lot of these issues might be relatively easy to find with a little intelligent Googling or asking Stack Overflow. But that time might have been better spent continuing development on the current project. And that time can add up.
My story was a C# WPF application and certain events were not being unregistered. It wasn't the language built in event registration but a weak even registration handler in a WPF library.
It wasn't unregistering the event and it was odd to say the least because it was just an equals call. It turns out that the function was an anonymous function (that was defined as x = {...};) The strangest thing is that the anonymous function had a reference to it and I had thought that the references were being compared for equality.
But it wasn't being matched... So I recommended the inline declaration be changed to an actual static method and the comparison worked. I think I gave some kind of explanation about how it most likely compared the address of the methods or something. Or the comparer for a Action<T> was different than "normal" objects. Half the fun of it is figuring out how things really work behind the scenes though. For the person figuring it out though.
http://cppquiz.org/quiz/question/38
The answer is in the C++ name.
C++14's decltype(auto) confuses things even further: http://coliru.stacked-crooked.com/a/f7d8195efc4708f3
The question is what should someone say about his/her level of expertise when asked by a recruiter? I have been comfortably programming in the language for the past 15+ years, still feel shy about claiming myself to be an expert.
[1] http://herbsutter.com/2008/01/01/gotw-88-a-candidate-for-the...