Cppquiz – Figure what a given C++ program does

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 :)

Seriously declreftype would have been a much clearer way to signal intent here rather than making parenthesis significant.

After seeing this, I tried out the code and I'm now convinced that there is no way any one person could possibly know the entire C++ spec.

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.

Here is a JS one for you

    Array(10).join("hn" - 1) + " Batman!"

Pretty much. I tried three questions:

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.

I gave up after that. Yawn.

I can't quite tell due to the medium of text, but you make it sound like that's a bad thing. Was that your intended response?